Rob Stewart wrote:
This is, in essence, what I am proposing. I have now reworked the interface following Gennadiy's suggestion. Here's a glob_iterator that can recurse down directories:
class BOOST_GLOB_DECL glob_iterator : public iterator_facade< glob_iterator // Derived type , filesystem::path const // value_type , single_pass_traversal_tag > { public: glob_iterator() {} glob_iterator(std::string const & pattern, filesystem::path const & wd, glob_flags flags); private: ... };
I think you misunderstood what Gennadiy meant. (If not, I think this is a good idea, anyway.) Your function should accept an output iterator through which you save the results. That enables the caller to decide where the results go instead of you deciding that they go into a list which then must be iterated. Thus, I'm proposing something like this:
template <typename OutIt, typename Char> OutIt glob(OutIt & out, std::basic_string<Char> const & pattern, filesystem::path const & pathname, glob_flags flags);
Appropriate output iterators can forward the matches to a collection, to a GUI control, to a file, etc.
No need to parameterize on Char type. This thing uses filesystem to do the iteration over the contents of a directory and filesystem knows nothing of wide strings. We can/should revisit that later as and when filesystem is changed. As for the output iterator idea, I don't see how to use it. For example, with my suggestion I could populate an STL container with: namespace fs = filesystem; std::list<fs::path> const matches( glob_iterator("*.cpp", fs::path("."), glob_brace), glob_iterator()); How do I do that with your idea? Once you've explained it, can you tell me why it's better than glob_iterator, above? Angus (ever ignorant)