Boost logo

Boost :

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

At 04:12 PM 3/26/2002, Ross Smith wrote:

>-- You're still blithely ignoring the massive difficulty (impossibility
>without great gobs of nonportable code) of implementing is_readonly() on
>unixoid OSes.

I'm not ignoring it; I'm waiting to hear from UNIX/POSIX implementors to
see if others also think it is a problem. It isn't the world's most
important function, and I'll be happy to drop it if others agree it can't
reasonably be implemented.

>"!fopen(path,"a+")" is neither a useful specification (what if there's
>no more room on the disk?)

The point is you know that trying to open the file for writing will fail,
so you can fall back to a read-only strategy. It doesn't matter why. It
doesn't matter that a file may start out writable, but then fail because of
later disk space problems.

> nor a useful implementation (it would change
>the file's modification date if it's writable).

Only on O/S's that forced an implementor to actually attempt an open. And
the intended use is to see if some kind of modification has a chance of
success. So the file mod date is likely to be modified right away anyhow.

>-- What does is_empty() do? The name doesn't suggest anything to me. (If
>it's size==0, why isn't there a size() function?)

For a file, it's in effect size(path)==0. For a directory (which is the
particularly use case), it is

is_empty() will turn out to be particularly useful if the size attribute is
not universally available, or is not available for directories.

In an ideal world, boost/filesystem/directory.hpp,
boost/filesystem/attribute.hpp, and boost/filesystem/path.hpp would all be
designed together. But that wasn't happening. So I've tried to nail down
a reasonable directory.hpp interface.

Hopefully, Jan now has a known context for his work on file

And we do need to nail down boost/filesystem/path.hpp. The trick there is
to do it in a way that will work with operating systems well beyond the
POSIX/Windows orbit.

>-- create_directory() needs an option to create any necessary parent
>directories (mkdir -p). At least, I don't think it does that now; it's
>hard to tell from your description (branch? leaf?).

That's what the "recurse" option would do.

>-- There's a move() but no copy(). Oversight?

Cut-and-paste error. Did the cut, forgot the paste. Luckily, have backup!

>-- In the interests of generality, if you're only going to provide one
>conditional-delete function, it really needs to be the predicate one,
>not the regex one.

Yes, the predicate one would be more general. But for the "script-like"
target use, regex is probably the most common usage. People can hand code
other uses, I'm assuming.

Whether or not that is a good decision really won't be totally obvious
until people use the interface in real work. Easy enough to add predicates

Lambda really makes the predicate form more attractive, too.

> The latter is trivial given the former, but if you
>only have the latter, anything else has to be hand-coded. On the other
>hand, I'm dubious about the need for selective-delete operations in
>general: hand-coding them is easy; I don't see any reason why
>selective-delete would be more useful than any of the other
>selective-whatever functions that aren't there; and I can think of any
>number of operations that I'd put in a file handing library before
>-- Top of that list would be is_ordinary_file() vs is_special_file().

Those will be high on the attribute/properties list perhaps, but I'm not
sure they deserve special is_xxx() functions.

>Others I'd like to see (from a quick vgrep through my own code):
>-- Functions to split a path into its component parts. (Is this what
>branch + leaf do?)

boost/filesystem/path.hpp will provide functions to lexically operate on

There has been some though about is_relative(path) and is_absolute(path),

>-- Function to resolve a relative path into a fully qualified absolute

Probably. I need to do some research first.

>-- Other properties of a file. size() and last_modified() are the
>obvious ones.

Attributes/properties. Coming.

Thanks for the comments,


Boost list run by bdawes at, gregod at, cpdaniel at, john at