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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2013-03-24 14:47:07

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

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.

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

It seems that the designer of the library does not like the idea that path
be a higher level platform independent abstraction of paths. As I'd say
many times I see little use in the current path class, and I personally use
UTF-8 std::strings everywhere with suitably defined operations. 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.

-- 
Yakov