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

Subject: Re: [boost] [filesystem] Request for comments on proposedrelative()function
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2014-05-16 11:31:13

On 2014-05-16 17:32, Peter Dimov wrote:
> Yakov Galka wrote:
>> On Fri, May 16, 2014 at 4:20 PM, Peter Dimov <lists_at_[hidden]> 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 <ybungalobill_at_[hidden]> 
>> 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