On Fri, May 16, 2014 at 11:41 AM, Gavin Lambert
... Again, I don't think relative(*, some-relative-path) is a sensible operation.
Besides, relative(absolute(path1, X), absolute(path2, X)) == relative(absolute(path1, Y), absolute(path2, Y)) for any X & Y when both paths are non-rooted relative; any cwd injection will cancel out.
Absolute is not relevant to the definition. I feel we lost each other. To make it constructive, do you agree with my definition: relative(x,y) returns a path z (unique up to equivalence), if exists, such that y / z = x (up to equivalence) ? Here I'm using the abstract definitions of / and equivalence, which may vary depending on the effect you want to achieve.
And finally, the working dir of each drive is not actually filesystem state. It's environment state, separately owned by each process (albeit inherited from its parent). So you're not actually accessing the filesystem when you get the CWD.
You still access some state external to the given paths. This is what I want to avoid. True, but there isn't a good answer to that unless you can determine what
the cwd of c: is (or just assume it's the root, which is a bad idea especially for console programs). Which means this case depends on "filesystem state" -- though actually environment. ... (Which is apparently what Boost.Filesystem does, but only when using system_complete() instead of absolute(). I'm not sure why these have different behaviour; system_complete() seems more sensible.)
This is exactly what I am telling! You either want to combine paths, this is what / is for (in my definition), or complete them with some current system-dependent state, which is what system_complete() does. (Sometimes you want to do both, in that order.) To get an absolute path on Windows (using today's boost.fs), one has to call system_complete(), *not* absolute() (!!!), because the later does not capture platform semantics correctly.
This all sounds good, but working with paths relative to an *unknown* base
is useful. Think of some project directory that tries to be relocatable.
I don't see how that would be a problem. It can use absolute(path-in-config-file, path-of-project) to obtain the "real" location of some resource while running, and then write it back using relative(real-location, path-of-project). You're free to move the project and its resources around between runs and the links will be preserved as long as the internal structure is maintained.
Don't you think that resolving two paths w.r.t. the same base, just in order to get the difference between them, shows that relative of two relative paths make sense on its own? If you read carefully the definitions in my OP, the relative() I described has exactly this property: for relative paths it works as-if assuming both have all possible bases prepended (same base for both). An unknown base is only something that exists in storage. To actually
accomplish anything useful, you need to know what the actual base is. (It's usually not sensible to manipulate the path by itself -- you have to do the same manipulation [eg. renaming] to the actual resource or you'll break the link.)
How about getting a relative path between two files in a project? I.e. one pointing to another. -- Yakov