Re: [boost] boost::filesystem::path frustration

Subject: Re: [boost] boost::filesystem::path frustration
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2013-01-25 16:55:09

On Fri, Jan 25, 2013 at 6:30 PM, Beman Dawes <bdawes_at_[hidden]> wrote:

> [...] Not particularly elegant, but this does work:
>
>        path x("/foo/bar");
>        path y("/foo/baar");
>
>        auto result = std::mismatch(x.begin(), x.end(), y.begin());
>
>        path prefix;
>        for (auto itr = x.begin(); itr != result.first; ++itr)
>           prefix /= *itr;
>
>        std::cout << prefix << std::endl;
>

This code doesn't work on windows, as I described in my previous post.

>  > Why should paths be so different from everything else?  I think, if the
> > design is actually right, some rationale is sorely needed.
> >
> > Also,
> >
> > * (**) the docs don't say what the value_type of path::iterator is.  A
> >   string value?  A range that becomes invalid when the path is
> >   destroyed?  Ah!?!  How surprising; inspecting the code shows it
> >   iterates over paths!  A container whose element type is itself is very
> >   unusual!
>
> It is a kludge to deal with the type of the contained string being
> implementation defined and not necessarily the type the user wants. In
> other words, a misuse of path to supply string interoperability. The
> returned type should ideally be a basic_string, with begin() and end()
> templatized on the string details, but I didn't think of that until
> recently.
>

Well, in this particular issue no-one said that iterator::value_type must
be a string. Let it be a path_element, since (--end()).extension() still
seems to be useful. (Or maybe let extension() be a free-standing function
operating on arbitrary strings?)

As per "string being implementation defined", you must already know my
opinion. This is a bad design choice. A non-templatized path means shoving
the user a concrete character encoding and memory allocation scheme. Now,
please follow the following argument:

The rationale for using the "native" encoding is that it is supposed to be
frequently passed to/from the system, and therefore supposedly being
inefficient if done otherwise. *But* the high-level path operation that are
(supposed to be) provided by boost::path are usually done in a higher-level
code. Now, if I use narrow UTF-8 strings in my code, then there will be
more UTF-8 → UTF-16 → UTF-8 conversions (on windows) than actual calls to
the system. Therefore, it is more logical to let the user choose when she
likes to do the conversion to the system encoding (if at all) and provide a
narrow boost::path as it has been in Boost.FSv2.

Cheers,
-- 
Yakov