Subject: Re: [boost] [filesystem] Request for comments on proposed relative() function
From: Beman Dawes (bdawes_at_[hidden])
Date: 2014-05-14 13:39:35
On Wed, May 14, 2014 at 3:12 AM, Rob Stewart <robertstewart_at_[hidden]>wrote:
> On May 13, 2014 10:00:25 PM EDT, Gavin Lambert <gavinl_at_[hidden]>
> >I'm assuming that the intended use case of this is to "minimise" a path
> >given a known working directory, and unrelated absolute paths are
> >already in their minimal form in that context.
> That's a reasonable use case, but this function is only about returning
> the portion of p that is relative to base.
> >Or another possibly useful output (as Daniel hinted at, though I don't
> >think he got the case right) would be to return a relative path using
> >dotdot syntax, so:
> >BOOST_TEST(fs::relative("/abc", "/abc/def") == path(".."));
> >BOOST_TEST(fs::relative("/ghi", "/abc/def") == path("../../ghi"));
> >This could be more useful in some cases (it bloats the path but makes
> >more immune to being moved elsewhere). Maybe we even need both.
The function has now been renamed from relative() to lexically_relative()
to make clearer that it deal with paths at a purely lexical level.
I probably should have mentioned that work is underway on several
additional functions to "do-the-right-thing" when the paths exist or
partially exist in the external file system.
On possibility is to add a semi_canonical() function which behaves like
canonical() for an existing portion of a path, and then normalizes any
trailing non-existent portion.
This would allow an additional function that does the right thing for
existing or partially existing paths. It might be implemented like this:
path relative(const path& p, const path& base)
return lexically_relative(semi_canonical(p), semi_canonical(base));
It isn't clear yet if these semantics are really the most useful.
> >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
> >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.
Thanks to both Gavin and Rob for their comments,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk