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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2013-03-23 12:13:04

Beman Dawes <bdawes_at_[hidden]> writes:

> On Sat, Mar 16, 2013 at 12:54 PM, Alexander Lamaison <awl03_at_[hidden]> wrote:
>> I'm finally getting round to moving to Filesystem v3 and now my code is
>> breaking all over the place.  The cause is the output of string() on
>> Windows which has changed behaviour.
>>
>> I'm manipulating Unix paths for use over SFTP, but doing so on Windows.
>> For instance I might want to append "c" to the Unix path "/a/b".
>>
>> path p("/a/b");
>> p /= "c";
>> cout << p.string();
>>
>> In version 2 this would output "/a/b/c" but now it produces "/a/b\c".
>> Why the breaking change?
>
> IIRC, it was partially requests from users and partially the
> realization that most users want platform independent syntax but
> platform dependent semantics.

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.

But, the biggest issue is that the change wasn't documented.  The docs
make a big deal of the change from templated paths to a single path
class, but make no mention of this, more significant, difference.

> If you would rather continue to use operator /= then change the output to
>
>     cout << p.generic_string();

I've since discovered this string/generic_string/native triplet.  I
don't think it's the right solution.  string() should either return the
generic string or the native string.  What it returns at the moment is
confusing and not very useful.  Or is there a use-case I'm not seeing.

Alex

-- 
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)