From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-09-27 14:52:17
> >> fs::path const starting_directory(".");
> >> std::list<fs::path> const matches =
> >> boost::glob("../te?t/foo*bar", starting_directory);
> >
> > This look way too inefficient. Why would you want to copy list of
complex
> > objects? Iterator interface seems much better fit here.
>
> Hi, Gennadiy.
>
> Rich Johnson's original proposal was for
>
> class glob_iterator
> : public filter_iterator<
> glob_predicate<>,
> filesystem::directory_iterator>
> struct glob_iterator {};
>
> Indeed, I've retained this, although I shoved it into namespace
> boost::detail.
>
> The problem is that this glob_iterator will iterate only over the contents
> of a single directory.
Why? Because of filesystem::directory_iterator? Use different implementation
> Moreover, good implementations of the system glob
> require that:
>
> In order to have access to a pathname, this function requires
> search permission on every component of a pathname except the last,
> and read permission on each directory of any filename component
> in @c pattern that contains a wild card.
>
> which means that you *shouldn't* use glob_iterator if the component does
> not contain wildcards.
Sorry. It's out of scope of my understanding. Maybe filesystem experts could
comment on that. Or you could rephrase it.
> Would you be happy if I changed the interface to:
>
> std::list<fs::path> matches;
> boost::glob(matches, "../te?t/foo*bar", starting_directory);
It slightly better, but I still prefer iterator interface. What I am going
to do with above list? Most probably I a mgoing to iterate through it to do
somethins, or find simething. What if I only need first matching element? We
have several years expirience now with container/iterator alternatives. I
believe iterator interface is more natual here (and ultimately more
efficient).
> If not, could you expand further?
>
> Regards,
> Angus
Gennadiy.