Re: [boost] Filesystem Library: Formal Review

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-17 09:26:25

Beman Dawes wrote:
> At 05:57 AM 9/17/2002, Vladimir Prus wrote:
> 
>  >1. Say I have a path. I want to treat it as relative to some other
>  >directory, if it is relative. That is, I want function
>  >
>  >     path root ( const path& p, const path& r )
>  >
>  >which will work like
>  >
>  >     root ( "/home/ghost/a" , "/home/ghost" ) = "/home/ghost/a"
>  >     root ( "a" , "/home/ghost" ) = "/home/ghost/a"
>  >
>  >How can I do that? I seems rather hard currently -- I see no way to join
>  >two paths
> 
> Operator <<= and operator << do that, if I understand your question.
> 
> To take your second example,
> 
>      path p( "home/ghost" );  // the starting path
>      ...
>      foo( p << "a" );    // p << "a" yields temporary path "home/ghost/a"
>      p <<= "a";          // afterwards, p.generic_path() == "home/ghost/a"

This works nice here, but in a more complex example:

     path base("/home/ghost", system_specific);
     path p("a/b/c/d", system_specific);

How do I join base with p? Do I need to manually split p in components?

     path base("/home/ghost", system_specific);
     path p("/a/b/c/d", system_specific);

Here, even if I manage to split 'p' into components, what will they be? 
I guess, "", "a", "b", "c", "d". What is the semantics of

    base <<= ""

>  > and I see no way to tell if a path is relative.
> 
> Let's take your example:
> 
>      path p( "/home/ghost", system_specific );
> 
> and assume we add a path member function "bool relative() const" (and 
> possibly add a leading "/" to the portable grammar). Is this true or false:
> 
>      p.relative()  // true or false?
> 
> The answer depends on the operating system.  For POSIX-like systems, the 
> answer is false. For many other operating systems the answer is true 
> (because they are multi-rooted.)
> 
> That scares me because programs using relative() easily code constructs 
> which won't be portable. It's the illusion-of-portability problem.

I understand your concern, but in absense of 'join' I think some 
functionality is lost. I'm not arguing for 'relative' member, I'm 
agruing for some form of 'join' now.

>  >2. I haven't found any treatment of relative paths in docs. It appears
>  >that they are accepted and treated relatively to the current dir, but
>  >isn't relying on current dir considered bad? How can I avoid it, if I
>  >can't implement the function 'root' above?
> 
> Here is the approach that seemed to work well in various initial uses of 
> the library:
> 
> First, nail down a base directory, either from user input:
> 
>     path base( argv[1], system_specific );
> 
> or from the initial directory:
> 
>     path base( initial_directory() );
> 
>   if ( exists( base << "foo" ) ) ...

Again, what if I have path 'p', created from user input, and want to 
join base with it?

> Note that the library doesn't currently enforce the above approach. You 
> can code create_directory( "bar" ) and it will work fine, although it is 
> anybody's bet what directory "bar" will end up in; the implementor is 
> only expected to do what is natural for the operating system (which may 
> have no concept of current directory).

Maybe this should be stated explicitly in docs?

- Volodya