This function will work most of the time, but every now and again it will run across a directory which it will claim isn’t one. Why?
The problem is caused because dwAtts is a bitfield (see the GetFileAttributes() documentation). Simple equality comparison isn’t appropriate, as if the directory has any other attributes (such as compressed, hidden, offline, etc.) the comparison will fail.
This is a style issue, so there is no right or wrong, but I suggest using a const reference for an input-only paramater to a C++ function and a pointer for an input/output or output-only parameter. This makes it slightly more obvious that the parameter might be modified by the function.
Example:
ReturnTypeFunction(constParamType&inputParam,ParamType*inputOutputParam,ParamType*outputParam){// ...
}voidUser(){ParamTypeinputParam;ParamTypeinputOutputParam;ParamTypeoutputParam;// Note the &s -- this is a bit of a warning something
// might happen to inputOutputParam or outputParam...
ReturnTyperet=Function(inputParam,&inputOutputParam,&outputParam);}
If my experience is typical, this is a very common construct:
ReturnTypeFunction(conststd::vector<T>&container){typedefstd::vector<T>::const_iteratoriterator_t;for(iterator_titer=container.begin();iter!=container.end();++iter){// Work with *iter
}}
The problem with this construct is that you have forced a container choice upon the user of your function. Slightly better, and basically your only choice when interoping with C, is this:
ReturnTypeFunction(T*array,intnumItems){for(inti=0;i<numItems;++i){// Work with array[numItems]
}// Or perhaps:
// for (T* pT = array; pT != array + numItems; ++pT) {
// Work with *pT
// }
}
With the above construct you can pass in any container which uses contiguous storage, such as an array or a std::vector (yes, std::vectorsare guaranteed to store the data contiguously). Passing a std::vector to the above function looks like:
I’ve seen the following STL construct countless times:
std::vector<T>container;for(inti=0;i<container.size();++i){// Work with container[i]
}
Unless otherwise necessary, it is better to use an STL iterator because it enables you to more easily change the underlying container. You can isolate the code changes required to one line by using typedef, as in:
typedefstd::vector<T>container_t;container_tcontainer;// Or ::const_iterator as necessary
for(container_t::iteratoriter=container.begin();iter!=container.end();++iter){// Work with *iter
}
Note that I wrote iter != container.end() as opposed to iter < container.end(). The former only requires an input iterator, while the latter requires a random access iterator—a more complicated iterator type supported by fewer STL containers.