Re: [boost] Filesystem Library: Formal Review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-17 10:31:38

At 10:12 AM 9/17/2002, Peter Dimov wrote:

 >I've been trying to understand your point of view but I still don't see 
how
 >you avoid the current directory with the above.
 >
 >Consider the case (assume POSIX for clarity) where the user input is 
"foo".

Yes, but that isn't a portability problem because on an operating system 
that doesn't support the concept of relative path the user would have to 
enter an absolute path.

In other words, the program is portable, but the user input is system 
specific, and that is exactly the functionality we want.

 >Your base path is relative, and as such, it inherently depends on the
 >current directory. In order for the program to function as intended, 
"foo"
 >must be interpreted as relative to initial_directory() even if the 
current
 >directory changes while the program is running, but the library does not
 >provide a way to do that.

That's a strong argument for providing some additional functionality, but 
exactly what should the semantics be?  That's been the hold up all along.

Let's see.  Here is the code we would like to write:

    path p( argv[1], system_specific );
    if ( p.xxx() ) p = initial_directory() << p;

Say the user input is "foo" - p.xxx() should be true.

Say the user input is "/foo" (or "c:/foo" on Windows) - then p.x() should 
be false.

So far, so good. Here comes the problem: what if on Windows the user input 
is "/foo".  That needs to return false.

So if xxx() is named relative(), to have it return false is very 
misleading. That is what has been hanging me up.

How about incomplete() as a name?

    path p( argv[1], system_specific );
    if ( p.incomplete() ) p = initial_directory() << p;

 >In effect, the library works as intended only if the current directory
 >doesn't change.

 > But if the current directory is assumed to never change, it
 >is no longer "evil" to provide a way to access it, as it is a global
 >constant.

Exactly.  That was the rationale behind the initial_directory() semantics.

Thanks for the help on this; it has been bothersome.

--Beman