Subject: Re: [boost] [filesystem] Request forcommentsonproposedrelative()function
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2014-05-18 13:56:28
On Sun, May 18, 2014 at 8:35 PM, Peter Dimov <lists_at_[hidden]> wrote:
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk