Gavin Lambert
On 20/08/2015 02:55, Beman Dawes wrote:
The full proposal is at http://boostorg.github.io/filesystem/relative_proposal.html ... 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?)
In theory, the filesystem library has to work for operating systems other than POSIX and Windows, and some legacy system use different syntax for directories vs files. So a trailing "/" is significant on such systems because it signifies a path to a directory rather than a path to a file. Since iteration doesn't return the directory separator, a trailing "." gets added to signify a directory. In practice, all operating systems now supply a way to work with POSIX format paths. So I guess some of the rules could be simplified. I'll give that some thought.
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")
That's correct.
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
They are all unrelated, so return path().
(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.)
These are all lexically relative, so do not throw (except if out of memory).
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.
Yes, that refers to another section of the doc this proposal is updating. That sentence is typically present for operational functions that may run into I/O and other errors when they access the actual file system, but not for functions that do not access the actual file system. Thanks, --Beman