Re: [boost] Filesystem Library: Formal Review

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-17 11:01:15

From: "Beman Dawes" <bdawes_at_[hidden]>
> At 10:12 AM 9/17/2002, Peter Dimov wrote:
>  >Your base path is relative, and as such, it inherently depends on the
>  >current directory. In order for the program to function as intended,
> "foo"
>  >must be interpreted as relative to initial_directory() even if the
> current
>  >directory changes while the program is running, but the library does not
>  >provide a way to do that.
>
> That's a strong argument for providing some additional functionality, but
> exactly what should the semantics be?  That's been the hold up all along.
>
> 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);

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