Boost logo

Boost :

From: Ami Tavory (atavory_at_[hidden])
Date: 2005-01-26 17:42:36


  Hello,

  I have some questions encountered while attempting to extend the
boost::filesystem library (BTW, thanks to all involved with this excellent
library).

  I often need to do something with all files matching certain criteria
which reside (recursively) in subdirectories matching some (probably
different) criteria. E.g., I might want to list all *.hpp files in all
subdirectories of 'develop', or search for the first *.cpp file in all
subdirectories of "my_proj" excluding "my_proj/bin".

  Using the boost::iterator library (BTW, thanks to all involved with this
excellent library as well), I built a recursive_directory_iterator,
parameterized by a functor indicating whether to expand a subdirectory, and
a filter iterator, parameterized by a functor indicating whether to retain
an entry with a given path, which filters the sequence formed by some other
underlying iterator (e.g., recursive_directory_iterator, in this case).

  This led to two questions:
1. Does the library already include similar functionality? (I couldn't find
any;) If not, are there any pitfalls involved?
2. There are (at least) two ways to implement recursive_directory_iterator,
which display a memory/time tradeoff: (a) using a stack of
boost::filesystem::directory_iterator, and (b) using a
boost::filesystem::directory_iterator (for the current subdirectory) and a
boost::filesystem::path (for the (parent) subdirectory entry to which to
return once the current subdirectory is exhausted). Consequently, I made
this too a policy of recursive_directory_iterator.
  Version (b), however, throws an exception when trying to iterate over a
subdirectory "foo!": specifically, I can't assign "foo!" (or any name
including '!') to a boost::filesystem::path object, although it seems that
my filesystem (on Windows XP) finds "foo!" an acceptable name for a
subdirectory. Should I be using boost::filesystem differently?

  Many Thanks,

  Ami


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk