From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-17 11:38:56
At 12:01 PM 9/17/2002, Peter Dimov wrote:
>> Let's see. Here is the code we would like to write:
>> path p( argv, system_specific );
>> if ( p.xxx() ) p = initial_directory() << p;
>path p( argv, system_specific);
>path q = make_absolute(p);
Interesting. That could have some other advantages. For example, the very
fact of its existence would would alert people that "solidifying" paths is
a worthwhile practice.
>Note that make_absolute doesn't treat p as relative to initial_directory,
>but as relative to the current directory. For rationale, consider the
>- program starts, initial_directory() is captured
>- program calls lib A that changes the current directory
>- program gets a relative pathname from lib A (or lib B); that pathname
>relative to the current directory, as the originating library has no
>concept of "initial directory."
The past arguments for some form of explicit access to the current
directory also come down to that same scenario; the need to interact with
some other library which expects explicit current directory access and or
>- program needs to "solidify" that pathname for later use, as it expects
>that it will call lib A again.
>As an enhancement, make_absolute can be made to accept a second argument,
>the "logical" current directory.
>I see less need for the reverse operation, make_relative.
I don't either. The most common need to make a relative path is for the
element most distant from the root. path::leaf() already provides that.
I'll give make_absolute() some more thought. Might be a nice addition.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk