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

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
<andrey.semashev_at_[hidden]>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