ansaurus

Question

How might I wrap the FindXFile-style APIs to the STL-style Iterator Pattern in C++?

Answer 1

+3 A:

To solve the first problem, you can have end() return some sentinel value, then in your iterator's increment function, set the iterator equal to that sentinel value when it reaches the end of the container. This is effectively what the directory iterator in Boost.Filesystem does.

For the second problem, I'm not entirely familiar with the FindXFile APIs, but one option would be to return some struct that contains all the data you need or that has member functions to get each of the pieces of data you might want.

James McNellis 2010-03-28 04:22:16

+1 for earliest answer that solves both problems.

Billy ONeal 2010-03-28 04:44:59

Using a `WIN32_FIND_DATA` with `.dwAttributes` set to `DWORD(-1)` works quite well as a sentinel. Normally, `FILE_ATTRIBUTE_NORMAL=0x0080` can't be combined with other flags like `FILE_ATTRIBUTE_DIRECTORY==0x0010`.

MSalters 2010-03-29 15:46:15

Answer 2

+3 A:

Matthew Wilson has written several articles on adapting directory enumeration to STL iterators. Unfortunately, the article that directly addresses the Windows APIs doesn't seem to be online anymore. However, I imagine the ideas that are discussed in some of his other articles are probably still very relevant, and he also provides an open source library (WinSTL - http://winstl.org/) with the Windows implementation.

Also, I'm sure that the Boost::Filesystem source and documentation is a great source of ideas.

Michael Burr 2010-03-28 04:37:23

+1 for Boost::FileSystem source suggestion.

Billy ONeal 2010-03-28 04:44:27

Try the url http://www.drdobbs.com/windows/184416631

dcw 2010-04-15 05:41:33

Answer 3

+5 A:

Interestingly, I had the same idea some time ago. Here's what I wrote up:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <string>
#include <iterator>
#include <exception>

#ifndef DIR_ITERATOR_H_INC
#define DIR_ITERATOR_H_INC

class dir_iterator

#if (!defined(_MSC_VER)) || (_MSC_VER > 1200)
    : public std::iterator<std::input_iterator_tag, 
                            std::string, 
                            int, 
                            std::string *, 
                            std::string &> 
#endif
{ 
    mutable HANDLE it;
    std::string mask;
    std::string path;
    WIN32_FIND_DATA data;
    bool done;
    DWORD require;
    DWORD prohibit;
public:
    WIN32_FIND_DATA operator*() { 
        return data;
    }

dir_iterator(dir_iterator const &other) :
    it(other.it),
    mask(other.mask),
    path(other.path),
    data(other.data),
    done(other.done),
    require(other.require),
    prohibit(other.prohibit)
{
    // Transfer the handle instead of just copying it.
    other.it=INVALID_HANDLE_VALUE;
}

    dir_iterator(std::string const &s, 
        DWORD must = 0,
        DWORD cant = FILE_ATTRIBUTE_DIRECTORY)
        : mask(s),
        require(must),
        prohibit(cant & ~must),
        done(false),
        it(INVALID_HANDLE_VALUE) // To fix bug spotted by Billy ONeal.
    { 
        int pos;
        if (std::string::npos != (pos=mask.find_last_of("\\/"))) 
            path = std::string(mask, 0, pos+1);

        it = FindFirstFile(mask.c_str(), &data);
        if (it == INVALID_HANDLE_VALUE)
            throw std::invalid_argument("Directory Inaccessible");

        while (!(((data.dwFileAttributes & require) == require) &&
                ((data.dwFileAttributes & prohibit) ==  0)))
        {
            if (done = (FindNextFile(it, &data)==0))
                break;
        }
    }

    dir_iterator() : done(true) {}

    dir_iterator &operator++() {
        do { 
            if (done = (FindNextFile(it, &data)==0))
                break;
        } while (!(((data.dwFileAttributes & require) == require) &&
            (data.dwFileAttributes & prohibit) == 0));

        return *this;
    }

    bool operator!=(dir_iterator const &other) { 
        return done != other.done;
    }
    bool operator==(dir_iterator const &other) { 
        return done == other.done;
    }

    ~dir_iterator() { 
        // The rest of the bug fix -- only close handle if it's open.
        if (it!=INVALID_HANDLE_VALUE)
            FindClose(it);
    }
};

#endif

And a quick demonstration of it:

#include "dir_iterator.h"
#include <iostream>
#include <algorithm>

namespace std { 
    std::ostream &operator<<(std::ostream &os, WIN32_FIND_DATA const &d) { 
        return os << d.cFileName;
    }
}

int main() { 
    std::copy(dir_iterator("*"), dir_iterator(), 
        std::ostream_iterator<WIN32_FIND_DATA>(std::cout, "\n"));

    std::cout << "\nDirectories:\n";
    std::copy(dir_iterator("*", FILE_ATTRIBUTE_DIRECTORY), dir_iterator(), 
        std::ostream_iterator<WIN32_FIND_DATA>(std::cout, "\n"));

    return 0;
}

Jerry Coffin 2010-03-28 04:38:18

+1 -- though correct me if I'm wrong here -- doesn't that call FindClose() on garbage data when the default constructed iterator is destructed?

Billy ONeal 2010-03-28 04:41:43

@Billy:now that you mention it, yes, I think it does. I'll have to fix that. One of the benefits of posting code is getting a bug caught now and again -- thank you.

Jerry Coffin 2010-03-28 04:47:13

@Jerry Coffin: One more bug -- if the iterator is copied then FindClose() will be called twice on the same handle. Just don't call STL algorithms on this LOL!. Giving you the checkmark for the demonstration.

Billy ONeal 2010-03-28 04:50:44

@BillyONeal:at least in theory, you're right. So far, I've never seen a problem from it (or the other bug) though; I'm guessing that `FindClose` is smart enough to do nothing if what you pass it isn't a valid search handle. In theory the right answer would probably be an implementation object with a ref-counted wrapper.

Jerry Coffin 2010-03-28 05:00:20

@BillyONeal:Thinking about it a bit more, in this case ownership transfer semantics are probably fine -- I'll edit the code a bit to do that.

Jerry Coffin 2010-03-28 05:07:52

Yeah -- I tried the refcounted wrapper method but that broke because when any instance of a copied iterator had `operator++` called, it was implicitly called on all instances of that iterator ( There's no way to duplicate a search handle :( ).

Billy ONeal 2010-03-29 14:35:21

@Jerry Coffin: I have edited my answer with what I eventually settled on in case you are interested.

Billy ONeal 2010-04-08 04:12:44

Answer 4

+1 A:

Unless you're doing it to learn, my answer would be: don't, it's already been done. The STLSoft libraries contain the winstl::basic_findfile_sequence class template that handles most/all use cases for searching a Windows directory, including wildcards, multi-part patterns (e.g. ".xls|.doc"), reparse points, and more. It's documented in great detail in Matthew Wilson's in-depth treatise on STL extension "Extended STL, volume 1: Collections and Iterators". The book's a major read, but it contains all the things you'll want to know (as well as many you may not) about writing STL extensions.

If you need recursive search, then consider the recls library (another of Wilson's), which also provides an STL interface, via the recls::search_sequence class. See here for a bunch of examples from a recent article about it.

dcw 2010-04-15 05:39:44

That library doesn't support recursive searches.

Billy ONeal 2010-04-15 12:06:19

Ah, my bad. Have just updated my answer to include the recls library.

dcw 2010-04-16 02:34:30

Answer 5

+1 A:

Try the recls library, discussed here. (It's also available for .NET, fwiw.)

DannyT 2010-04-16 05:54:42

ansaurus

tags:

views:

answers:

How might I wrap the FindXFile-style APIs to the STL-style Iterator Pattern in C++?

related questions