Re: [Boost-users] [filesystem] Relative Draft Proposal RFC

Subject: Re: [Boost-users] [filesystem] Relative Draft Proposal RFC
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-08-24 10:20:59

Gavin Lambert <gavinl <at> compacsort.com> writes:

> 
> 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