RE: [boost] Re: relative/absolute paths in filesystem library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-26 15:17:41

At 09:14 PM 11/25/2002, Glen Knowles wrote:

 >I'm dealing with filesystem paths and urls and the way we ended up
 >implementing it is with the following functions (we are not currently 
using
 >boost::filesystem, these are from an internal library):
 >
 >current_directory() - returns the current directory (and drive if 
windows)

That's been added, per the formal review. The actual names for it and its 
sibling function will be current_path() and initial_path(), to reflect the 
fact that a path rather than just a directory name are returned.

 >is_absolute() - true if the directory (sans drive) starts with a / (c:/, 
/,
 >/blah are absolute; c:blah, blah, ../blah are not)

That's been added too.

Hum... On multi-rooted operating systems like Windows, "/" and "/blah" are 
relative to the current drive, and thus not considered absolute. AFAIR, 
that was mentioned several times and was not controversial. What was your 
rationale?

 >make_absolute() - prepends current drive if no drive is defined, inserts
 >current directory after the drive if it is not an absolute path

If I understand you correctly, make_absolute() and resolve() differ in that 
the source of the "base" path in make_absolute() is hardwired. Because the 
"base" path is always absolute with make_absolute(), result is always 
absolute.

 >resolve(base, rel) - returns a path that is 'rel' resolved relative to
 >'base' according to the following table:
 >base     rel      result
 >-----------------------------
 >base     rel      base/rel
 >base     /rel     /rel
 >base     c:rel    ... throws exception
 >base     c:/rel   c:/rel
 >/base    rel      /base/rel
 >/base    /rel     /rel
 >/base    c:rel    ... throws exception
 >/base    c:/rel   c:/rel
 >c:base   rel      c:base/rel
 >c:base   /rel     c:/rel
 >c:base   c:rel    c:base/rel
 >c:base   c:/rel   c:/rel
 >c:base   a:rel    ... throws exception
 >c:base   a:/rel   a:/rel
 >c:/base  rel      c:/base/rel
 >c:/base  /rel     c:/rel
 >c:/base  c:rel    c:/base/rel
 >c:/base  c:/rel   c:/rel
 >c:/base  a:rel    ... throws exception
 >c:/base  a:/rel   a:/rel

These semantics seem carefully worked out, and there are probably cases 
where they are exactly what is required.

On the other hand, these semantics are complex, and may cause confusion. It 
is easy to incorrectly assume the result is always absolute. The 
preconditions and postconditions seem unclear. Are exceptions are being 
thrown for what are really preconditions?

Thomas Witt pointed out that with a full set of decomposition functions to 
grab portions of a path, it becomes easy to write code like:

    if ( !p.absolute() ) p = current_path().root_path() / 
p.relative_path();

or

    if ( !p.absolute() ) p = initial_path() / p.relative_path();

These semantics aren't the same as your resolve() or make_absolute(), but 
may be what is required for some applications.

I'm planning to make the other changes suggested by the formal review, but 
not add any composition functions. I'll then ask for a mini-review to get 
comments. It is much easier to add functions later than to remove functions 
once they go in.

Thanks for the comments,

--Beman

--Beman