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
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:
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:
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.
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]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk