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

Subject: Re: [boost] boost::filesystem::path frustration
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-01-25 11:30:26

On Thu, Jan 24, 2013 at 8:56 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> I'm finding that boost::filesystem::path seems to be a strange mix of
> different beasts, unlike any entity we have in the STL.  For example,
> when you construct it from a pair of iterators, they're expected to be
> iterators over characters, but when you iterate over the path itself,
> you are iterating over strings of some kind (**).  Even though, once
> constructed, this thing acts sort of like a container, it supports none
> of the usual container mutators (e.g. push_back, pop_back, erase) or
> even queries (e.g. size()), making it incompatible with generic
> algorithms and adaptors.

It isn't really a container, but it is convenient to supply iterators
over the elements of the contained path. Should more container-like
mutators be supplied? I'm neutral - they would occasionally be useful,
but add more signatures to an already fat interface.

> In particular, this comes up because I'm trying to find the greatest
> common prefix of two paths.  I thought this would be easy; I'd just use
> std::mismatch.  But even once I've found the mismatch I don't see any
> obvious way to chop off the non-matching parts of one of the paths.  I
> end up having to resort to some really ugly code (or I just haven't
> figured out how to use this thing correctly).

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;

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

> * the docs claim you can construct a path from a "A C-array. The value
>   type is required to be char, wchar_t, char16_t, or char32_t", but
>   doesn't say how that array will be interpreted.  From the wording I
>   might have assumed it accepts a CharT(&)[N] and the length of the
>   input is taken as N, but inspecting the code shows it expects a CharT*
>   and interprets the source as null-terminated.

I'll make some doc changes per your comments above.

--Beman