Re: [boost] [filesystem] Request for comments on proposed relative() function

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]>
> wrote:...
>

> >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
> >it
> >more immune to being moved elsewhere).  Maybe we even need both.
>
> Interesting
>

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

+1

Thanks to both Gavin and Rob for their comments,

--Beman