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.