Re: [boost] Re: New design proposal for boost::filesystem

From: Andrew Green (ag_at_[hidden])
Date: 2004-08-30 16:41:21

On Aug 30, 2004, at 13:18, David Abrahams wrote:
>> At 02:48 PM 8/26/2004, Carlo Wood wrote:
>>
>>> ...
>>> What do you think about my proposal(s)?
>>>
>>> I (too?) think that an important improvement can be made by
>>> making an explicit distinguishment between relative and
>>> absolute paths.
>>
>> Dave was talking about changes to the path grammar. IIRC, he was not
>> suggesting adding additional path types.
>
> I do think Carlo's idea is intriguing.

This is almost identical to the approach I've been using for the last  
couple of years. We have two classes used by application code:
* ZFileTrail is our analogue of Carlo's fs::relative_path. It's a list  
of steps through a hierarchy -- each step is either a 'bounce' that  
moves you to the parent of the current node, or it's the name of the  
child to descend into.
* ZFileSpec is the entity that tends to actually get used most of the  
time. Under the hood it contains a ZFileLoc, akin to Carlo's  
fs::native_path, and a list of steps further down the tree.

Applying a ZFileTrail to a ZFileSpec often ends up only manipulating  
the spec's list of steps and we don't have to hit the file system at  
all, at least until we actually try to use the referenced node.

ZFileSpec has three static pseudo-constructors, ZFileSpec::sCWD(),  
sRoot() and sApp(). They return a ZFileSpec representing whatever the  
platform considers to be the current working directory, the root of the  
file system and the file holding the executable, respectively; the last  
isn't always available, of course.

Recently I've been working mostly on command line apps, where I've  
found the three standard locations to be entirely sufficient. The  
intent is to have further pseudo-constructors or free-standing  
functions that return ZFileSpecs for other locations of interest --  
temp and prefs directories mainly, but also the numerous different  
'system' folders MacOS defines.

One thing I've added locally but not yet checked in is a distinction  
between getting the child of a ZFileSpec, and applying a trail to a  
ZFileSpec. In the former case there's no interpretation of the string  
that's passed in, in the latter the string is assumed to be using POSIX  
notation and is converted to a ZFileTrail, preventing the use of  
slashes in filenames (very common on MacOS/MacOSX).

You can see the code at  
<http://cvs.sourceforge.net/viewcvs.py/*checkout*/zoolib/zoolib/src/ 
file/ZFile.cpp?rev=1.21> (the POSIX-specific stuff is at  
<http://cvs.sourceforge.net/viewcvs.py/*checkout*/zoolib/zoolib/src/ 
platform/posix/ZFile_POSIX.cpp?rev=1.34>).

I doubt that the style of the code will meet with the approval of  
anyone on this list, but it might be of interest and in any case I  
wanted to voice my support of the basic approach.

A+
-- 
Andrew Green                           mailto:ag_at_[hidden]
Electric Magic Co.               vox: [phone]