Boost logo

Boost Users :

Subject: Re: [Boost-users] [filesystem] Relative Draft Proposal RFC
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-19 20:32:44


On 20/08/2015 02:55, Beman Dawes wrote:
> The full proposal is at
> http://boostorg.github.io/filesystem/relative_proposal.html
>
> A preliminary implementation is available in the feature/relative2
> branch of the Boost Filesystem Git repository. See
> github.com/boostorg/filesystem/tree/feature/relative2
> <http://github.com/boostorg/filesystem/tree/feature/relative2>
>
> The overall plan is to get feedback from boost developers, then merge to
> develop for boost 1.60, then propose to the C++ committee for addition
> to the Filesystem TS.
>
> Comments welcome. If you are one of the many people who have requested
> "relative" functionality, does this proposal meet your needs? If not, why?

Looks good so far. (I've only looked at the proposal document, not the
code.)

There's a few things that strike me as curious (I'm sure there are
reasons for them though):

1. Why is the normal form for "/some/path/" equal to "/some/path/."
instead of "/some/path"? Doesn't that violate the "no redundant current
directory elements" rule? (I assume it's related to the root path being
weird, but maybe it would be better to make the root path an exception
rather than cluttering the general case?)

2. For relative(path), it appears to be unspecified (at least in the
example assertions) what happens when unrelated paths are used. I would
expect the following:
    path("/a/b/c").relative("/d/e/f") == path("../../../a/b/c")
    path("/a/b/c").relative("d/e/f") == path() or exception
    path("a/b/c").relative("/d/e/f") == path() or exception
    path("a/b/c").relative("d/e/f") == path() or exception
  (Arguably the second might not be an error -- provided the first path
is absolute [which isn't true for the above on Windows] then it could
return the first path without modification; this would still technically
be a valid path but it wouldn't be a relative one, which is why I think
an error is more appropriate.)

3. "Throws: As specified in Error reporting." I assume this refers to
some other document, as it does not appear to refer to anything in this
one. Also it seems odd that this clause is omitted on the earlier
functions.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net