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

Rob Stewart writes:

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.

Where exactly the parsing happens if an implementation detail. What matters is how class path 'thinks' about paths and, in many respects, class path abstracts away from separators. For example path("a/b").filename() return "a" not "a/b" on Windows. The problem is that part of the interface ignores separators. The other part makes them significant. It's a mess. One or the other please.

...

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.

And yet that's exactly what it used to do. If this change has been made as an 'optimisation' we should be worried. Making an interface less clear for a hypothetical optimisation is the kind of thing that we learn not to do in software engineering 101.

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.

Actually the truth is worse than that: native() doesn't convert the slashes to native format. It just allows a string to contain both generic and native separators, so now I don't understand the difference between string() and native() at all.

...

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.

Not needed as this works already. See my other post. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)