Boost logo

Boost :

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
file/ZFile.cpp?rev=1.21> (the POSIX-specific stuff is at

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.


Andrew Green                           mailto:ag_at_[hidden]
Electric Magic Co.               vox: +1 (831) 621 1822

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