Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at