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

Subject: Re: [boost] boost::filesystem::path frustration
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-27 10:41:59

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

> On Friday 25 January 2013 18:45:30 Dave Abrahams wrote:
>> on Fri Jan 25 2013, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>> > 
>> > 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.
>
> In my previous reply to Yakov I explained why I don't see path as a container. 
> You seem to want to work with paths like with vector<string_ref> but I don't 
> think this is portable. You don't know what the string_ref contains and what 
> restrictions apply to the content on the particular platform. 

I don't care about those restrictions.  I'm happy with the set of
algorithms that will work when string_refs can be compared.

> E.g. on Windows it can contain a subdirectory name or a drive prefix
> (e.g. C:).

I'm well aware.  It wouldn't make a bit of difference to my use case or
many others.

> Also, working with extensions or otherwise modifying file names like
> adding suffixes, etc.  fall below the vector<string_ref> interface, to
> the character level. 

Yes.  So what?  We already have strings for that purpose.

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