On Sun, Mar 24, 2013 at 8:03 PM, Alexander Lamaison
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. 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. -- Yakov