Re: [boost] Filesystem Library: Formal Review

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.xxx() ) 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
 >scenario:
 >
 >- 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 
is
 >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 
manipulation.

 >- 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.

Thanks,

--Beman