Boost logo

Boost :

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[1], system_specific );
>> if ( ) p = initial_directory() << p;
>Or perhaps
>path p( argv[1], 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, gregod at, cpdaniel at, john at