From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-09-28 10:57:33
> 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.