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

Subject: Re: [boost] boost::filesystem::path frustration
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-25 18:45:30

on Fri Jan 25 2013, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

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

As soon as you can iterate it and append path elements (and you can
now), push_back, insert, and erase make wonderful sense.  I understand
exactly what those operations should mean, and I have use cases to boot!

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

Why?  IME path manipulation almost universally occurs on directory
boundaries, so xposing a character-based interface as the primary one
for path seems counter-productive.  IMO there should be a way to get to
the underlying characters if you want them, but the primary interface
should be a container of pahth elements.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost