Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk