Introduction

Several times I worked with file names, I usually used Win32 API such as ::FindFirstFile.. But it turns out that it's so boring work. Finally, I realized I can use STL's great feature, iterator, to handle file name iteration. That's why I made a simple STL iterator class for file name iteration.

You also can fill the STL container by using the constructor that takes begin iterator and end iterator.

Actually, win32_file_iterator class' constructor takes three parameters. The first one is the filter string that is for calling ::FindFirstFile function. Second one is the flag that specifies whether dereferenced path is full path or not. For example, if it's true, the returned path string is c:\test\aa.txt, otherwise it'll be aa.txt only. The last parameter is the other flags which specify file attribute. For simplicity, I used Win32 API's FILE_ATTRIBUTE_XXX flags..

If you want to get only directory names, and which is full path, the code will look like this:

Comment

The code might have many terrible bugs. But what I want was to show the way we can use STL like iteration to find filenames. I wish it'll help you. You can use this code in whatever ways you want, comments are welcome..

And also check out boost::filesystem library.. it's well-written but a little bit heavy. It needs an additional DLL, I suppose.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

* Referencecounting related issues: The presented implementation has a number of issues, and hardly ever works except for the most trivial case. To illustrate this, take a look at this code snippet:

win32_file_iterator* pwfit = new win32_file_iterator( "C:\\*.*" );
win32_file_iterator wfit = *pwfit;
delete pwfit;
// wfit still holds a reference to the original HANDLE that has just been
// closed, with a reference count of 2.

Similar issues exist for the auto-generated assignment operator. A possible solution could be to use a static std::map<HANDLE, unsigned int> _handleReferences; member, and to insert code that deals with self-assignment, both for the copy-c'tor and the assignment operator.While this solves the issues of reference counting, a more significant issue still remains: since the FindXyzFile API calls aren't stateless, a shared resource introduces a more severe problem. Operating on any given iterator potentially also silently modifies the state of another, in a worst-case scenario even to a point where it's state goes out of sync (see _bEnd).

* operator== and operator!=: First of all, unless there is a reason not to (like performance issues), these operators should always share a common implementation, i.e. operator!= should be expressed in terms of !operator==. More importantly, though, they should expose proper semantics. In the current implementation, all iterators are split in 2 groups, with members in each one comparing equal to any given other of that same group.

* post- and prefix increment operators: Again, the semantics are off. While the prefix operator is fine as it is, the postfix operator should return a temporary value that reflects the state of the iterator prior to the operation.

To sum it up, once you get rid of the shared handles, the remaining troublesome operators will be more natural to implement, and on top of that, expose more accurate semantics.