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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-03-24 17:51:21

On Mar 24, 2013, at 2:47 PM, Yakov Galka <ybungalobill_at_[hidden]> wrote:

> On Sun, Mar 24, 2013 at 8:03 PM, Alexander Lamaison <awl03_at_[hidden]>wrote:
> 
>> Rob Stewart <robertstewart_at_[hidden]> 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)