On 16/05/2014 19:21, quoth Yakov Galka:
Though I suppose for consistency with absolute/canonical, relative() could use absolute(base) as its base internally, which would produce reasonable results (albeit somewhat dependent on filesystem state -- but that's not unexpected when dealing with relative paths).
It is unexpected for me -- when I'm dealing with paths I don't want to access the filesystem at all, unless I specifically say that.
But you *are* specifically saying that by not supplying an absolute path as your base path. 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. 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.
absolute("c:foo", "c:/bar") == "c:/bar/foo"
This requires that case.
And absolute("c:foo", "d:/bar") == "c:/bar/foo"... It does not make sense.
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. (And it's not arbitrary state -- it's state that's set either earlier in your own process or by your parent process possibly in preparation to execute you. So it's not unreasonable to depend on it.) But it's not correct to treat this as an invalid case either. Imagine a console program that is trying to translate a user-supplied argument (the first parameter) into an absolute path based on its CWD (the second parameter). Both the program and the user should expect, by convention, that the previously-used-WD of C: should be used in the expansion. As in: cd /d c:\baz cd /d d:\bar zap quux c:foo The parameters are well defined and should expand to d:\bar\quux and c:\baz\foo respectively. (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 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. 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.)