From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-18 18:01:24
At 04:10 PM 9/18/2002, Rob Stewart wrote:
>From: "Peter Dimov" <pdimov_at_[hidden]>
>> path p( argv, system_specific);
>> path q = make_absolute(p);
>How about this:
>path p(argv, make_absolute);
>The term "absolute" implies system specific, and this approach
>avoids the extra step of calling make_absolute().
Definitely an interesting idea, but I'd like to settle the semantics 100%
before worrying too much about what amounts to the syntax. See below.
>> Note that make_absolute doesn't treat p as relative to
>> but as relative to the current directory. For rationale, consider the
>Yes, the "make_absolute" notion must make an absolute pathname
>appropriate for the system. That means it must specify a path
>starting with "/" for Posix systems, a drive letter for DOS-like
>> As an enhancement, make_absolute can be made to accept a second
>> the "logical" current directory.
>I think that's worthwhile. Consider the case in which the
>"logical current directory" comes from some other programmatic
>source such as a configuration file or other user input. Since
>Boost.FileSystem doesn't (and quite reasonably shouldn't) offer
>the means to change the current directory, you can't effect the
>"logical current directory" behavior any other way.
I think there are actually three valid choices for supplying absolute root
(1) The current directory (and drive, volume or other system_specific
(2) An explicitly supplied path (via a second argument.)
(3) can be coded explicitly as the second argument with the interface
having to make any special provision, but we might want to make it the
Another thing that has to be nailed down is what happens with various
boundary conditions. For example:
absolute( "foo", "bar" ) // Oops, 2nd arg isn't absolute
absolute( "foo", "c:" ) // Oops, 2nd arg isn't absolute on Windows
absolute( "foo", "/bar" )// Oops, 2nd arg isn't absolute on Windows
absolute( "" ) // What does this return?
The third one is particularly tricky because it is perfectly valid for
POSIX but not for multi-rooted systems like Windows.
Also, note that the 2nd and 3rd are system specific, but I don't think that
should be implied.
Basically, it is necessary to allow system specific paths, and access to
the current directory, drive, etc. but they should always be slightly ugly
(so people think twice about using them), and easy to find with grep-like
tools (so they can be found in source code). IOW, same rationale as the
new-style cast syntax.
A another question is that in effect we are making the current directory
available by calling absolute() with the right arguments, so would it be
better (in addition to absolute()) to just go ahead and add a
current_directory() function? Or a special path constructor?
And finally, how do we specify absolute() so that it still gives reasonable
behavior on an operating system which has no concept of current directory?
Need to think about it a bit more.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk