Subject: Re: [boost] [filesystem] Request for comments on proposed relative() function
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-05-14 19:02:11
On 14/05/2014 21:12, quoth Rob Stewart:
>> In the event that the provided path cannot be made relative to base,
>> isn't it more generically useful to return the original unmodified
>> absolute path? (ie. simply returning p instead of throwing, at least
>> when both paths are absolute.)
> This gets you into the discussion of error codes versus exceptions
> as a means to report errors.
Not really; I was asking if this case should be considered as an error
at all. I can see a fairly likely use case of "translate this absolute
path to one that is relative to my current working dir", for which
sometimes a perfectly acceptable answer is "the original absolute path".
>> Although that brings up another question (which I'm not really familiar
>> enough with the "path" class internals to answer by looking at the
>> example implementation): is "base" intended to be assumed as a
>> directory name (which is how most filesystem "make relative"
>> functions typically work) or as a file name (which is how URL "make
>> relative" works)?
> path makes no assumptions about what it references, or whether the
> pathname even exists in the filesystem.
I'm aware of that; my point was that the semantics of the "make a
relative path" operation typically differ between filesystems and URLs.
For example (imagining some hypothetical functions):
make_relative_uri("http://foo.com/baz/bar", "http://foo.com/baz") ==
make_relative_uri("http://foo.com/baz/bar", "http://foo.com/baz/") ==
make_relative_path("/baz/bar", "/baz") == "bar"
make_relative_path("/baz/bar", "/baz/") == "bar"
Essentially, URLs always assume any trailing component that does not end
in a slash is a filename, and will make paths relative to the containing
directory of that file. While filesystems generally assume that the
base is a directory name regardless of whether it has a trailing slash
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk