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,
> >must be interpreted as relative to initial_directory() even if the
> >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, system_specific );
> if ( p.xxx() ) p = initial_directory() << p;
path p( argv, 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
- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk