Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at