From: Jeff Garland (jeff_at_[hidden])
Date: 2002-09-23 08:39:54
> >Directory Iterator comments:
> >* I couldn't get the recursive_iterator working. Without docs, its
> > not clear what the Predicate stuff is. This needs to be documented
> > and should be part of the library. Unless there is good reason
> > recursive behavior should just be part of the directory_iterator
> > constructor. That is:
> > fs::path p(...some path...);
> > fs::directory_iterator(p, fs::recursive); //default is non-recursive
> I hadn't thought of that. I'll try to work out the details to see how it
> would work in practice. It might be a nice symplification.
> Predicate was partially just an experiment on my part, because I noticed
> that recursive directory iteration often involved filtering. I wanted to
> see how a Predicate would work, per discussions on the Boost list last
Ok, good. Filtering is something that might be useful in both
regular or recursive iteration. One example that comes up
pretty frequently for me is ignoring all the backup files
that end in '~' created by certain editing tools.
> Well, mold or no mold, operator<< has worked well in practice. It writes
> well, it reads well, it doesn't seem to be error-prone. Changing to
> operator / will make it even better.
> I understand the concerns. I had them too, but the "append" interface was
> not good to use in practice. When I changed to the operator>> interface,
> and changed existing code to use it, the code read ever so much better.
Ok, I'll be happy as long as it isn't <<.
> The docs changes I made in response John Maddock's comments will improve
> the situation slightly, but while reading your comment it occurred to me
> those two functions could be made free-functions, and moved into a
> sub-namespace (which is part of the official interface) with a name like
> "native" or "detail". Thus they would still be available, but it would be
> ever so much more obvious they aren't intended for everyday use.
Sounds like a plan :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk