Re: [boost] Filesystem Library: Formal Review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-18 18:01:24

At 04:10 PM 9/18/2002, Rob Stewart wrote:

 >From: "Peter Dimov" <pdimov_at_[hidden]>
 >>
 >> path p( argv[1], system_specific);
 >> path q = make_absolute(p);
 >
 >How about this:
 >
 >path p(argv[1], make_absolute);
 >
 >The term "absolute" implies system specific, and this approach
 >avoids the extra step of calling make_absolute().

Definitely an interesting idea, but I'd like to settle the semantics 100% 
before worrying too much about what amounts to the syntax.  See below.

 >> Note that make_absolute doesn't treat p as relative to 
initial_directory,
 >> but as relative to the current directory. For rationale, consider the
 >
 >Yes, the "make_absolute" notion must make an absolute pathname
 >appropriate for the system.  That means it must specify a path
 >starting with "/" for Posix systems, a drive letter for DOS-like
 >systems, etc.
 >
 >> As an enhancement, make_absolute can be made to accept a second 
argument,
 >> the "logical" current directory.
 >
 >I think that's worthwhile.  Consider the case in which the
 >"logical current directory" comes from some other programmatic
 >source such as a configuration file or other user input.  Since
 >Boost.FileSystem doesn't (and quite reasonably shouldn't) offer
 >the means to change the current directory, you can't effect the
 >"logical current directory" behavior any other way.

I think there are actually three valid choices for supplying absolute root 
information:

   (1) The current directory (and drive, volume or other system_specific 
root information.
   (2) An explicitly supplied path (via a second argument.)
   (3) initial_directory()

(3) can be coded explicitly as the second argument with the interface 
having to make any special provision, but we might want to make it the 
default behavior.

Another thing that has to be nailed down is what happens with various 
boundary conditions.  For example:

    absolute( "foo", "bar" ) // Oops, 2nd arg isn't absolute
    absolute( "foo", "c:" )  // Oops, 2nd arg isn't absolute on Windows
    absolute( "foo", "/bar" )// Oops, 2nd arg isn't absolute on Windows
    absolute( "" )           // What does this return?

The third one is particularly tricky because it is perfectly valid for 
POSIX but not for multi-rooted systems like Windows.

Also, note that the 2nd and 3rd are system specific, but I don't think that 
should be implied.

Basically, it is necessary to allow system specific paths, and access to 
the current directory, drive, etc. but they should always be slightly ugly 
(so people think twice about using them), and easy to find with grep-like 
tools (so they can be found in source code). IOW, same rationale as the 
new-style cast syntax.

A another question is that in effect we are making the current directory 
available by calling absolute() with the right arguments, so would it be 
better (in addition to absolute()) to just go ahead and add a 
current_directory() function?  Or a special path constructor?

And finally, how do we specify absolute() so that it still gives reasonable 
behavior on an operating system which has no concept of current directory?

Need to think about it a bit more.

Thanks,

--Beman