On Sun, Mar 24, 2013 at 9:12 PM, Alexander Lamaison
Yakov Galka
writes: [...] That's not true. It does parse the string and recognises "a" and "b" as separate segments of the path. If it didn't, iteration would return "a/b" followed by "c". I wrote a small program (included at the end) to prove this. Here is the output:
Based on previous conversations with Beman, I think that what Rob Stewart means, and correct me if I'm wrong, is that one "feature" of the library is the assertion path(str).string() == str.
It does now. It didn't used to and I'm struggling to see what the benefit of the change was. After all, if all you want is the original string why would you even use the path class.
These are exactly my thoughts..
[...]
It seems that the designer of the library does not like the idea that
path
be a higher level platform independent abstraction of paths. As I'd say many times I see little use in the current path class, and I personally use UTF-8 std::strings everywhere with suitably defined operations. What annoys me is that Boost.filesystem has a fairly good multiplatform implementation of filesystem operative functions, but which depends on this dumb path class.
I wouldn't write off the path class entirely. It was what first got me in to Boost all those years ago! But it could be better and some of the recent changes don't make sense to me.
I admit that a path class is a matter of preference. But this is why it is unfair that exists(const path &x) uses a path in its interface towards those who do not like using this class. -- Yakov