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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2013-03-25 08:46:13

Rob Stewart <robertstewart_at_[hidden]> writes:

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

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)