On Sun, May 18, 2014 at 8:35 PM, Peter Dimov
Yakov Galka wrote:
I don't follow. The real-world use-case is that I have some config/project/database/install-dir named x = "c:/myproduct", that references another file y, conceptually relative to itself. I think we all agree that if y = "a.txt" then x / y = "c:/myproduct/a.txt" is the desired result. Now, if y = "/windows/a.txt" I would definitely expect the result to be "c:/windows/a.txt", and not "/windows/a.txt" which may end up resolved to "d:/windows/a.txt" if "d:" is the current drive. How "/abc" is any different from "a.txt" in this respect?
Yes, exactly.
Now my point is that if you prefer /windows/a.txt to be resolved to c:/windows/a.txt, you should also prefer c:a.txt to be resolved to c:/myproduct/a.txt. ...
Yes, I prefer it to be so. Unfortunately it means that either * we need to represent some of the program state affected by the previous concatenations in a string form, which is not encodable in a system understandable syntax, or * give up associativity, or * process drives independently of the rest, like "d:/a/b/c" / "c:" = "c:/a/b/c" (this is what boost::filesystem::absolute does), or * acknowledge that Windows paths are so crazy that the best we can do is x / "c:" = "c:", always. Do you see another option? (The last option isn't that bad: it's just that "c:" always means the "per-drive current directory of drive c", whereas "/" is the root of the drive of THE current directory.)
In other words, /a and c:a are equally absolute.
Treating c:a as absolute and /a as relative doesn't quite make sense to me.
As I said, you can detach absolute() from concatenation, by defining it in terms of system_complete(), in which case both become relative (as desired) independently of which option above you choose. -- Yakov