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

On Sun, Mar 24, 2013 at 11:51 PM, Rob Stewart wrote: [...]

...

In other words: boost::path is a very dump strong typedef for a string

On Mar 24, 2013, at 2:47 PM, Yakov Galka wrote: 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.

Yes, but current path class does not abstract anything, as was pointed in the original post. [...]

...

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.

There are superior approaches for Unicode support: using UTF-8 narrow chars.[1] Why superior? Because the type of path[n], path.c_str(), path.string() etc. would not change from one system to the other. Portable libraries hide the differences between platforms rather than propagating them to the interfaces. I admit that maybe not everyone may agree on using narrow strings. But then, why shove your approach to those who don't like UTF-16 on Windows? Boost.Filesystem v2 was much better in this aspect too. If you like UTF-16 paths; use wpaths, if I like UTF-8 paths then I would use (narrow) paths with an appropriate locale embedded. And no, current library interface does not count: if I want to read a UTF-8 path from a database, do some arthmetic work on it, and store it back, for some reason the author of the idea jumped in the middle and decided that because I may potentially pass this string to Windows (and in this case I do not) he must convert my string to UTF-16 as soon as I gave it to him.... What a nonsense. Why cannot I choose the exact type I want to use: path...? The correct solution to make fopen("narrow string") work with Unicode is to require Unicode support in the standard, and this is a much simpler solution that has a larger impact than any path library can do. In part because it would solve it for C guys too, and in part because it requires only changes to the spec and implementation, no new bloated interfaces whatsoever.. [1] http://utf8everywhere.org/ -- Yakov