Boost logo

Boost :

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


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.

This is why I don't particularly like
>
> relative( d:/, c:a/b ) == c:a/b
>

I assume you meant relative( c:a/b, d:/ ).

-- c:a/b is not a relative path.
>
> Absolute, def :- path x is absolute when r / x does not depend on r.
>

Agree. Equivalent to my OP.

On an unrelated note, this c:a/b business sure throws a spanner in the
> works. It's absolute by the above definition...

Not exactly true. It depend on how you define x / "c:".

Definition 1:
x / "c:" = "c:" for all x. Then c:a/b is absolute.

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.

I do not imply that any of these interpretations is superior.

but it depends on the current directory of drive C... except that there is
> no such thing as a current directory of drive C in Windows, there's only
> one current directory per process... except that under DOS current
> directories were per-drive, so they are emulated today using hidden
> environment variables*.

Not exactly true. It's true that they are implemented for backward
compatibility reasons. But they are read by the Windows API, including
SetCurrentDirectory, GetFullPathName, etc... So there is still a per-drive
notion of "current directory" in addition to "THE current directory".

> Madness. How about we just say c:a/b is c:/a/b and be done with it.
>

It's a platform convention. Don't know about other systems (OpenVMS?).
Being Unix-centric is definitely easier. But if so, there is so much other
junk that can be simplified. Why not define narrow-char encoding be UTF-8,
say? After all, codepages are still supported only for backward
compatibility reasons. Seems to be a much more important and useful
assumption than the rarely used per-drive current directories... Smells
like hypocrisy to me.

-- 
Yakov

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk