Yakov Galka
On Sun, Mar 24, 2013 at 8:03 PM, Alexander Lamaison
wrote: Rob Stewart
writes: [...] In that case I'd expect it to output "\a\b\c". I can't think of a reason why mixed slashes would ever be the right answer. It's the worst of both worlds.
You're expecting this line
path p("/a/b");
to parse your string into "a" / "b" when it merely stores the string as you gave it.
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.
In other words: boost::path is a very dump strong typedef for a string that magically does encoding conversions and has some syntactic operations defined, like operator / that adds a *slash*. (...or a *backslash* on other platforms...)
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. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)