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

On 2014-05-16 17:32, Peter Dimov wrote:

Yakov Galka wrote:

...

On Fri, May 16, 2014 at 4:20 PM, Peter Dimov wrote:

...

Yakov Galka wrote:

relative(x,y) returns a path z (unique up to equivalence), if exists,

...

such that y / z = x (up to equivalence)

If you allow z to be an absolute path, it'd never be unique when x is absolute, because x would be a trivial solution then.

I think you got it backwords. x is the parameter, z in the solution. So yes, if x is absolute, then z is also absolute and equals x. Uniqueness isn't broken.

I don't think so.

x = c:/a/b y = c:/a

Good catch! I said I haven't checked it thoroughly :) My original thought and implementation used a notion of ranks, more as an implementation detail, so I left it out in my OP for the sake of simplicity. But I overlooked it matters in this definition. Basically higher rank elements erase the lower rank ones, highest rank is absolute. So here, rank(drive) > rank(root) > rank(regular), rank(x) = max rank of elements of x. You add the requirement that relative() returns a minimal-rank path, and I think you are ok with uniquiness on Windows and Unix.

That is not quite in the same category as the encoding, because it affects the path algebra, and encoding does not.

True. But path algebra is visible to the user, who has some expectations about it. In-memory encodings, on the other hand, are internal to the program. The question is whether you design a library for the sake of making a yet-another-c++-(standard)-library, or to ultimately deliver quality products to the end-users. On 2014-05-16 17:38, Peter Dimov wrote:

Yakov Galka wrote:

...

On Fri, May 16, 2014 at 4:49 PM, Yakov Galka wrote:

...

... Definition 2: "c:" / x / "c:" = "c:" / x "a:" / x / "c:" = "c:" for a != c and no element of x is a drive. This is similar to what SetCurrentDirectory does, and implies that c:a/b isn't absolute.

Actually the problem of this definition is that it cannot be associative given the current Windows path syntax.

To support c:a, we need either to distinguish between "c:" and "c:/" as path elements, or posit that c:/ consists of { "c:", "/" }.

The last time I checked, "c:/" was already parsed as {"c:", "/"} by boost. This is also the way implied in my OP.

The openat-based definition then becomes associative (using either), if I'm not mistaken.

You don't have openat on Windows, so you must approximate it for the sake of well defining this. Cheers, Yakov