Boost logo

Boost :

Subject: Re: [boost] boost::filesystem::path frustration
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2013-01-25 16:55:19

On Fri, Jan 25, 2013 at 6:49 PM, Andrey Semashev

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at