[boost] filesystem/directory example [was: ... header redux]

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-04-08 15:54:24

At 03:58 PM 4/1/2002, Jan Langer wrote:

 >On Mon, 1 Apr 2002, Stewart, Robert wrote:
 >>> I also think that reg. exp. matching should be done through a
 >>> predicate, if
 >>> nothing else to avoid the dependency of the filesystem
 >>> library the on reg. exp.
 >>> library.
 >>
 >>That's an excellent reason to rely on a predicate to handle the RE
 >pattern
 >>matching.  A standard predicate that uses an RE can be supplied in a
 >>separate header.  (Obviously, an overload of the function could be
 >supplied
 >>in that separate header, too.)
 >
 >i am also in favour of this. using predicates is more general. 
perhaps
 >we need only the predicate version which uses a return_true predicate 

 >as default argument. this would also solve the RE forward decl. 
header
 >problem because you only need the regexp header in the implementation 

 >of this predicate.
 >
 >probably it is possible to drop some of the options in favour of 
proper
 >predicates. for example using
 >	remove ("dirpath", optional);
 >with a functor optional
 >	class optional ...
 >	  bool operator () (std::string const &path)
 >	  {
 >	  	return exsts (path);
 >	  }
 >	  ...
 >	};
 >
 >and a class non_optional with
 >	bool operator () (std::string const &path)
 >	{
 >		if (!exists (path))
 >		{
 >			throw ...;
 >		}
 >		return true;
 >	}
 >which is the default argument.
 >
 >this could be a easy to use, extendible system which decouples the
 >options from the actual filesystem operation itself. the 
implementation
 >of remove has not to care for combinations of certain options a user
 >probably uses.

That deals nicely with some of the issues, but might have to be 
extended with a more general policy class to be able to take care of 
some of the other issues.  For example, whether or not to recurse into 
subdirectories.

One of the reasons I've delayed in answering this is that I wanted to 
build more experience actually writing some code.

See 
http://groups.yahoo.com/group/boost/files/filesystem/jam_regr_html.cpp 
for a program to generate regression test HTML from the residue left 
over from running boost-root/status/Jamfile.  An example of the 
generated HTML is 
http://groups.yahoo.com/group/boost/files/filesystem/jam_regr.html

The only filesystem features used directly were exists(), 
is_directory(), and the directory iterators. Indirectly, via the 
iterators, directory_contents was also used.

I wrote this code in the "script" mind set we postulated would be the 
common use.  It evolved quite a bit over time, but was very easy to 
write and at no point became unmanagable.  There were very few bugs 
during development, even though parts were hacked at night when I was 
tired and grouchy.

So I am feeling that exists(), is_directory(), and the 
directory_iterator and directory_contents classes are about right.

Notice the find_file function:

//  find_file  ------------------------------------------//
//  given a directory to recursively search

   bool find_file( const string & dir_path, const string & name,
     string & path_found, const string & ignore_dir_named="" )
   {
     for ( fs::directory_iterator itr( dir_path );
           itr != end_itr; ++itr )
       if ( fs::is_directory( itr->path() )
         && itr->name() != ignore_dir_named )
       {
         if ( find_file( itr->path(), name, path_found ) )
            return true;
       }
       else if ( itr->name() == name )
       {
         path_found = itr->path();
         return true;
       }
     return false;
   }

This is a convenience function we never envisioned when we were talking 
about remove, copy, etc.  But it was so easy to write (and then later 
hack by adding the argument ignore_dir_named so the code could be 
reused.)

Now you could say boost/filesystem/directory.hpp should contain a 
generalized version of such a function.  You could also say "Look how 
simple find_file() is! Maybe it shows we don't need the generalized 
copy() and replace() functions at all!"

Comments?

--Beman