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 15:32:47

On Sun, Mar 24, 2013 at 9:12 PM, Alexander Lamaison <awl03_at_[hidden]>wrote:

> Yakov Galka <ybungalobill_at_[hidden]> writes:
> [...]
> >>
> >> 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.
>
> It does now.  It didn't used to and I'm struggling to see what the
> benefit of the change was.  After all, if all you want is the original
> string why would you even use the path class.
>

These are exactly my thoughts..

>  [...]
> >
> > 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.
>
> I wouldn't write off the path class entirely.  It was what first got me
> in to Boost all those years ago!  But it could be better and some of the
> recent changes don't make sense to me.
>

I admit that a path class is a matter of preference. But this is why it is
unfair that exists(const path &x) uses a path in its interface towards
those who do not like using this class.

-- 
Yakov