Re: [boost] filesystem/directory.hpp header redux

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-26 21:07:24

At 03:20 PM 3/26/2002, Jan Langer wrote:

 >On Tue, 26 Mar 2002, Beman Dawes wrote:
 >>Attached is an updated version of boost\filesystem\directory.hpp.
 >>
 >>It uses the options approach discussed previously.
 >>
 >>It seems to me to be a lot cleaner and more usable than the previous
 >>attempt, which relied on explicitly named functions.
 >
 >- i am against directory_entry overloads. because they are only
 >sensible for the attribute like functions (is_... and exists). and
 >these functions can also be accessed by the real attribute system.

That makes sense.  We can always revisit the issue later.  I've removed the 
TODO.

 >- is the is() function intended to replace is_...() or just an addition.
 >in either case i like it. but we should wait until we have determined
 >how the attribute access system works.

It could be either, but I was thinking in terms of an addition. The 
exists() and is_xxx syntax is just so natural for the most common cases.

 > but we should wait until we have determined
 >how the attribute access system works.

Yes, agreed.  The code will stay commented out for now.

 >- i would replace the readonly-flag by writable and readable (and also
 >is_readonly by is_readable and is_writeable). this is much clearer.

I changed back and forth several times so obviously don't have a strong 
argument one way or the other.

What is your take on Ross Smith's assertion that it isn't possible to 
implement is_writable usefully on POSIX?

Part of the point of the few is_xxx functions is that they are always 
present and always give useful results.

 >- what does the prune option do? its value is the same as recurse (is
 >this intended) and shouldn't the comment be replaced by "operate only on
 >directory contents". please say a few more words on this.

The meaning of prune is to make directory removal conditional depending on 
whether or not the directory is empty.

For example,

    //  remove "foo", which must be empty, and must exist
    remove( "foo" );

    //  remove "foo", which must be empty, if it exists
    remove( "foo", optional );

    //  unconditionally remove "foo", and all its sub-directories
    remove( "foo", recurse );

    //  remove "foo", and any of its sub-directories, but only if empty
    remove( "foo", recurse+prune );

 >
 >- there is something wrong with the throw condition of create_directory.
 >perhaps it must be completely inverted.

Slightly garbled.  Fixed.  Thanks.

It is supposed to say that the function will throw on either of two 
conditions (in addition to the usual "may throw if can't complete"):

*  Unless the "recurse" option is on, the path except for the leaf must 
exist.

*  Unless the "optional" option is on, the path must not exist.

 >- i am in favour of the first move posibility (not make directories if
 >needed) b/c i think a more restricted default behaviour if good.

Agreed.

 >- why should directory_entry be deep copied?

That's really an implementation detail, so shouldn't be specified in the 
public interface.

The case to beware of is something like this:

    directory_iterator itr( "foo" );
    directory_entry first_entry( *itr );
    ++itr;  // this must not modify first_entry.

Since a directory_iterator in effect contains a directory_entry, an 
implementation could inadvertently modify the internal rep of first_entry 
if not careful. Deep copy solves that problem.

 >i think now its a easy interface which opens a quite large room of
 >possible operations. i like it :-)

I'm feeling a lot better about it.

Thanks for the careful reading.

--Beman