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

From: Jan Langer (jan_at_[hidden])
Date: 2002-04-08 17:30:55

On Mon, 8 Apr 2002, Beman Dawes wrote:
> >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.

i think there are two possiblities. either to drop most of the
convenience functions and provide only the functions which are
absolutely needed to write portable code.
or going the difficult way of providing an easy to use interface for
most of the cases which can occur (with recursion, non-throwing
versions, prune, predicates and other useful features).

in my opinion we should at first do the first step of writing only the
non-convenience functions and keeping the way open for a later
full-blown approach. this would be nearly the same like the earliest
version of filesystem lib.
i would like to see the effort goes into the open questions of path
manipulation and attributes rather than to discuss about probably
convenient additional functions which can easily performed by some
simple code.
for example it is not really necessary to have a function remove (path,
optional) if we can write
        if (exists (path))
                remove (path);

>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.

i looked at it and it is really easy to understand (altough i don't know
the regression test system). i totally agree with you. we should leave
these feature as they are.

>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!"

yes. if the discussion about useful features continues, filesystem will
never get finished. although discussions is never bad :-)
regards

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"