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

Subject: Re: [boost] boost::filesystem::path frustration
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-01-26 04:55:00

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. E.g. on Windows 
it can contain a subdirectory name or a drive prefix (e.g. C:). Also, working 
with extensions or otherwise modifying file names like adding suffixes, etc. 
fall below the vector<string_ref> interface, to the character level. In the 
end to write portable code you have to work with paths like with opaque 
identifiers, with abilities to extract some of its components (like filename 
and parent path) and compose new paths from them.

Note that I'm not saying that vector<string_ref> interface is not useful. But 
it is not needed for filesystem operations (like copying files) and it is not 
needed for basic and portable path processing (like getting a path from a 
config and appending a file name). Therefore this interface should be external 
from the path itself. IMHO, of course.