$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-01 15:03:28
"Jordan DeLong" <fracture_at_[hidden]> wrote in message 
news:20050601032618.GA23098_at_allusion.net...
> First;  pre-emptive apologies if this should be sent to boost-users
> instead of here (or I guess the Mod can nuke it and tell me).  I figured
> I should send it here because it's more of a design issue than a "how
> do I use this" issue...
>
> path::begin() is defined as returning an 'iterator' (not a
> const_iterator), so I figured I'd be able to write to it.
The docs describe iterator as " A const iterator..."
>  I wrote some
> code which did something like:
>
> fs::path p;
> /*...*/
> for (fs::path::iterator it = p.begin();
>        it != p.end();
>        it++)
>    if (*it == "FOO")
>        *it = "BAR";
>
> This errors because operator* on the iterator type returns a const
> string&.
>
> So:  was this a deliberate design decision?  I don't see anything about
> this in the design rationale stuff in the docs for Boost.Filesystem.
> Is there a good reason not to allow people to use the iterator to modify
> individual path elements?
Doing so would require actually maintaining elements internally as 
individual elements, say in a vector of strings. That would be pretty 
inefficient for most uses of path, just to support such uncommon usage.
Instead, rewrite your code something like this:
 fs::path p;
 /*...*/
fs::new_path new_p;
 for (fs::path::iterator it = p.begin();
        it != p.end();
        it++)
    if (*it == "FOO") new_path /= "BAR";
    else new_path /= *it;
HTH,
--Beman