Re: [boost] [Filesystem] v3 path separator changes

On Mar 24, 2013, at 2:47 PM, Yakov Galka wrote:

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:

path doesn't do that parsing. The directory iterator extracts a native path.

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.

Yes

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...)

Yes, path is a glorified string class. A fair bit of its value will be lost when there's better Unicode string support in the standard library. That said, there's still value in an abstraction that permits assembling and decomposing paths. If path did the normalization work, on insertion, or managed a collection of components, the overhead would increase. The current design permits assembling pieces in different ways and then, when a final result is needed, in a particular form, it offers three ways of getting the path: as assembled (string), generic, and native.

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.

It would be reasonable to support overloads accepting strings, and not just paths. The current rationale, I think, is to overcome the lack of any other Unicode support. ___ Rob (Sent from my portable computation engine)