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

[Beman Dawes]

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost