Ok, I've thought a bit and think I understand your proposal. Let's use a class to store the predicates that will be used to initialise the filter_iterators at each level of the tree:
class glob_pattern { vector<glob_predicate<> > predicates; };
Ie, "../foo*bar/baz?.eps" would require that glob_pattern stored a vector of 3 predicates.
Let's call these "filter_iterators at each level of the tree" glob_directory_iterators. A glob_iterator will store a vector of glob_directory_iterators. (Also 3 in the example's case). Incrementing a glob_iterator will use a strategy similar to the one you outline above.
class glob_pattern { vector<glob_predicate<> > predicates; public: glob_iterator begin() const; glob_iterator end() const; };
class glob_iterator { vector<glob_directory_iterator> dir_iterators; public: glob_iterator(vector<glob_predicate<> > const & p) { typedef vector<glob_predicate<> > p_vec;
dir_iterators.reserve(p.size()); p_vec::const_iterator it = p.begin(); p_vec::const_iterator const end = p.end(); for (; it != end; ++it) dir_iterators.push_back( glob_directory_iterator(*it)); }
glob_iterator operator++() { /* implement the "next" strategy */ } };
This strategy moves all the nonsense about "does the predicate contain wildcards or not" into glob_directory_iterator. Fine.
Looks Ok.
No doubt there's lots of implementation details left, (like using input_iterator_adaptor), but I think that this pseudo code covers the idea.
You may use iterator_facade also. I just found that implementing Input iterators using input_iterator_adaptor is easier. It's located in Boost.Test details derectory along with some usage examples.
Am I on the right track? Angus
Definitely. Looking forward to see it implemented. Regards, Gennadiy.