On Fri, Jan 25, 2013 at 6:49 PM, Andrey Semashev <andrey.semashev@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. 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.
What are those path-related functions that you will leave there? extension()? has_root()? Maybe these are also better to be free standing functions working on arbitrary strings? You are left with operator/, which also can be declared as string operator/(const string&, const string&); and be brought to scope with a using directive, for those who want to use it. Essentially you are left with a plain old string of a platform dependent encoding. This is what I said in my first post—thinking that "a path as a string" is applicable where you don't care for what is inside the path (in which case just use a string as a cookie), but in other cases it is nonsense. So please explain why "path should not pretend to be a container". I agree in general that implementing a view for iterating over path elements is an acceptable strategy, though. But in this case it is better to scrap the path class completely. Cheers, -- Yakov