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