Re: [boost] Re: New design proposal for boost::filesystem

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-08-31 08:34:04

On Tue, Aug 31, 2004 at 08:40:03AM -0400, David Abrahams wrote:
> > My most important analysis of practical use of paths from
> > a portable point of view was that an absolute path should
> > be considered to be _always_ native - hard coded in a type.
> > But not necessarily the other way around (a non-absolute
> > path can still be native as well).
> 
> I know you hate to answer such questions, but what problems does that
> solve?

Portability robustness of code.  I've given numerous of examples
in the meantime in other posts.

>From my post of 30 Aug 2004 (two posts earlier in this thread,
you even replied to it):

    Correct would be for example:

    #ifdef BOOST_WINDOWS
    fs::native_path root("C:/cygwin");
    #else
    // ...
    #endif

    fs::native_path np = root / "usr/src";

    if (exists(np))                         // Ok

and the fact that this should throw:

    fs::native_path np("/usr/src");         // Note, not possible to use fs::relative_path here (would throw).

    if (exists(np))                         // Should throw on cygwin (with BOOST_WINDOWS)
                                            // because the path is not complete!

Compare that with the current implementation:

    #ifdef BOOST_WINDOWS
    fs::path root("C:/cygwin");
    #else
    // ...
    #endif

    fs::path np = root / "usr/src";

    if (exists(np))                         // Ok

Now we 'forget' to use the 'root' there:

    fs::path np = "/usr/root";

    if (exists(np))			    // Returns 'false' rather than throwing.

The fact that it is possible to make a mistake like
that comes from the fact that the current implementation
doesn't enforce a truely portable "relative_path" type,
but allows one to use any "path value" for fs::path
"variables" and (ab)use them anywhere regardless.

The only way to catch the above mistake without
introducing a new type would be to test inside
fs::exists that the path that is being passed
is complete - and if not, demand that it is relative.
But that would be kludge and not attack the REAL problem
at the root.

> > The naming fs::native_path is essential thus and should not
> > be confused with a fs::absolute_path, that I did not propose.
> 
> Hm.

Note that the current implementation doesn't use the word
'absolute' - it speaks of 'complete'.  I take those two
as the same in this discussion.

Of course it would be possible to introduce another
level of paths and call that 'complete_path' - which
would be forced to be complete - or make itself
complete at construction if possible.  However, I
don't see must use for that - because it seems better,
more flexible, to delay that completion until the
path is actually being passed to a system call.
So, your proposal only would make sense to me if
you would not allow automatic conversion to a complete
path (ie: fs::complete_path("foo") would throw) so
that this type would be complete at all times.

But well, what does that solve? }:-)

-- 
Carlo Wood <carlo_at_[hidden]>