Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-23 11:32:26

At 08:37 AM 2/23/2002, Jeff Garland wrote:

>> I've written a design document for a file system library. See
>> y_design.htm
>> It is still rough, but should serve to focus discussions.
>Doesn't seem that rough :-)
>> Comments appreciated.
>>Be able to write portable script-style file system operations
>I think the 'scripting' inspiration is right on target. It might be
>mentioning that Perl and other scripting languages that provide these
>of libraries.

Added. Thanks.

>>Given a path, iteration (meeting std InputIterator requirements)
>>suitable for use in standard library I/O operations.
>If you don't have a current working directory then the iterator will need

>to return a full path in hierarchical systems, not just a name to be able
>to be able to open a file. Or am I missing something?

Since directory iteration requires a path, the path to the file can always
be composed from that path plus the returned name.

Note that the path give to the directory_iterator may in fact may be
relative to the current directory, but we don't know that. If so, then
when we compose the path to the returned name, we will get a path relative
to the current directory.

It seems to me this is a nice feature. The library need know nothing of
the current directory concept, yet programmers (or users, via some user
interface) who wish to rely on an O/S's current directory concept may do

>Also, don't we need a functions to distinguish between files and
>Something like:
>Given a path provide a function returning a bool that indicates if the
>is a file.
>Given a path provide a function returning a bool that indicates if the
>is a directory.

Yes, those are specific examples of attributes (or properties). Dietmar
Kühl (with refinements suggested by Jan Langer) has already suggested a
powerful interface to get/set a large list of attributes.

Thanks for the comments!


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