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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-27 09:56:51

At 10:33 PM 11/26/2002, Glen Knowles wrote:

 >From: Beman Dawes [mailto:bdawes_at_[hidden]]
 >
 > >>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.
 >
 >I'm not sure what initial_path() is, but I believe current_path()
 >should be current_directory() because:
 >
 >1. It is the common name for it.
 >2. What I want is a directory (the current one), a path might not be
 >a directory. I agree that current_directory_path() is better then
 >current_directory_name(), but the fact that its a directory is
 >what's important.

For both initial_xxx() and current_xxx(), xxx needs to path, and the 
returned type must be path. If the return type is path, then any of the 
path  elements (like drive, relative path, leaf directory, etc.) can be 
extracted by the path decomposition functions.

 >What would be the name for current_drive() ?

   current_path().system_specific_root()

The docs will include examples of all the decomposition functions for 
various typical paths.

 > >>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?
 >
 >I don't know if it was controversial, but I did bring this up during
 >the review and I do think its very important. The basic definition
 >of an absolute path should be a path that overrides the base path
 >during a resolve. To rephrase, 'foo' is relative because it is an
 >adjustment from the current directory, '/foo' on the other hand
 >takes precendence over the current path. To re-rephrase, '/foo' is
 >relative to the current drive, but not to the current directory.

That seems like a stretch to me. With your definition, "absolute" isn't 
equivalent to "not relative", and that seems counter intuitive.

Your definition can already be expressed as:

      !foo.root_directory().empty()

There has also been so consideration of providing has_xxx query functions, 
which would express the above as:

      foo.has_root_directory()

Pros: Expresses concept a bit more directly, may be implemented more 
efficiently than decomposition followed by empty().
Con: Fattens the interface.

If has_xxx query functions are provided, then there isn't really a need for 
a separate absolute query, since foo.has_root() (or 
foo.has_root_directory(), for those who prefer your definition.)

Not having a function named absolute() might be safest, too, because it 
would force users to choose exactly the has_xxx function they wanted, 
rather than jumping to a conclusion about the semantics of absolute().

 >I deal with URLs as much as with file paths and this does color
 >my thinking. The way I have outlined it I am able to use windows
 >drives and URL authorities with exactly the same semantics.
 >
 > >>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.
 >
 >There is more to it then that. make_absolute() uses the authority
 >(windows drive) given in the path if it is present, otherwise using
 >the current drive. So make_absolute(a:foo) is different from
 >resolve(c:/bar, a:foo) where c:/bar is the current directory, because
 >make_absolute(a:foo) is a request to make it absolute with respect
 >to the current directory of drive A.
 >
 >Referring to resolve. . .
 >
 > >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?
 >
 >There are really two basic rules. Resolving from one authority or drive
 >to another is illegal, and a path starting with a / is absolute with
 >respect to its authority.
 >
 > >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:
 >
 ><snip>
 >
 > >These semantics aren't the same as your resolve() or make_absolute(),
 > >but may be what is required for some applications.
 >
 >The semantics I'm arguing for are mandated for urls (RFC 1808 to name
 >one of many) and work well for file paths.

Understood. AFAIK, it is going to be possible to write both your 
make_absolute() and resolve() functions in a portable manner using path 
member functions.

I'm hoping to finish work on path (including docs) within a few 
days.  Perhaps you could then implement make_absolute() and resolve(), and 
post the results. At that point people will have enough information to 
decide if they are worth including in the library.

 >If I haven't said it before, thanks for all of your work on the
 >filesystem library (and boost in general), it is an important piece
 >missing from the standard.

Thanks; the comments and encouragement helps a lot.

--Beman