RE: [boost] Re: Design for a file system library

From: Jan Langer (jan_at_[hidden])
Date: 2002-03-08 20:02:12

On Fri, 8 Mar 2002, Stewart, Robert wrote:
>> > > root_directory() just returns a "name" that represents the systems
>> > > root "directory".  Above you claim that you want this directory
>> > > to "return" just '/', which indicates to me that '/' is the only
>> > > entry in the "directory" returned from root_directory().
>> This makes
>> > > it a "logical/psuedo/whatever" directory in the same sense that
>> > > a "root" directory in a DOS like system would be if we
>> follow Beman's
>> > > suggestion.  I'm not claiming to agree with this, I'm
>> just trying to
>> > > follow the logic in the posting.
>> >
>> >The problem is simply that there is no such thing as a
>> 'root' directory (in
>> >a portable world.) Under Windows, you can use
>> \\192.168.0.1\sharename and
>> >access the whole Internet if you like.
>>
>> I agree with this. Trying to make drives and UNC names appear like
>> directories seems fraught with problems. How about the other
>> approach.
>> Instead of a single root, you could introduce the concept of
>> volumes and
>> each volume has a root. On UNIX there would only be one
>> volume. On Windows
>> there would be, i.e., A:, C:, \\somecomputer\share, etc.
>
>This is nice.  "Volume" is the right abstraction for dealing with a
>filesystem.
>
>Perhaps we could go a step further and provide a collection of "system
>resources."  That would allow for all of the stuff in Windows' "Desktop" and
>anything else that a platform might offer.  The iterators for such a
>collection could be adapted to filter out all but volumes, thus giving what
>has been suggested previously (hierarchy_iterators).

i think there will be no result if we continue to discuss which "things"
are actually returned by a root-iterator. but there is a need for such
an special iterator. i read about four possible solutions:

(1) directory_iterator (root_directory ()) // function returning string
(2) directory_iterator (directory_iterator::roots); // enum
(3) hierarchy_iterator::begin (); // own class
(4) directory_iterator::roots (); // static member function

what this construct actually returns is impl.defined. i would prefer (4)
because its short to write, quite easy to implement and doesn't need an
additional class.
jan

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