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

Subject: Re: [boost] boost::filesystem::path frustration
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-01-25 11:49:06

On Friday 25 January 2013 11:30:26 Beman Dawes wrote:
> 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.

IMHO, path should not pretend to be a container. Things like push_back, 
insert, erase don't make sense with respect to it. It could provide begin/end 
iterators over underlying characters but just to implement other algorithms. 
Iterating over path elements (i.e. what is currently achieved with begin/end) 
should probably be an external tool, like an iterator adaptor or a view on top 
of the path object. In the end it should become just a thin wrapper over a 
string, with a few path-related functions.