Re: [Boost-users] [multi_index] modify_range?

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-03-16 11:25:30

JOAQUIN LOPEZ MU?Z wrote:
> Jeff Flinn wrote:
>> It would be nice to have a modify_range/modify_key_range that would
>> apply a function object to each deref'd iterator in the range. Since
>> the multi_index iterator derefences to a const value_type&, one can
>> not use std::for_each in particular to apply modifications. Or am I
>> missing something.
>
> Hello Jeff,
>
> I think it is possible to have what you want
> without requiring that a new facility be provided
> by Boost.MultiIndex itself. For you can write:

[snipped code]

> There is a problem, though: consider the following:
>
> // buggy call ro modify_range
> modify_range(m,m.begin(),m.end(),adder(2));
>
> What's the problem with this? Well, after *increasing*
> the value of an element, this is repositioned
> further to the end of the container, and consequentely
> modify_range will visit it again and engage in a
> neverending loop (modulo overflows.)

Would modifying a non_key(or non_derived_key dependency) ever cause 
repositioning?

> For this situations
> you can use a special (albeit slower) variation that
> records the range before starting modifying the
> elements:
>
>   template<typename Index,typename Modifier>
>   void modify_unstable_range(
>     Index& i,typename Index::iterator first,typename Index::iterator
> last,
>     Modifier mod)
>   {
>     typedef std::vector<typename Index::iterator> buffer_type;
>     buffer_type v;
>     while(first!=last)v.push_back(first++);
>
>     for(typename buffer_type::iterator it=v.begin(),it_end=v.end();
>         it!=it_end;i.modify(*it++,mod));
>   }
>
>   // calling modify_unstable_range is now OK
>   modify_unstable_range(m,m.begin(),m.end(),adder(2));

Doesn't this actually provide modify_key_range functionality?

> I hope my explanations are clear enough. Does this satisfy
> your needs? You can find attached a complete example
> exercising these little utilities. modify_key_range would
> be a simple variation on this stuff.

Yes this clearly explains the issues. From this it becomes clear that the 
best choice is to only insert objects with fully defined keys into 
multi_index containers. I was trying to avoid copies where possible.

In my case, I'm creating a container of objects, from a(n idiotic) stream 
format that spreads object members across disparate tables. So I've first 
created a vector of objects, modify all of their members as the data comes 
in. Then copy these to a multi_index container, and clear the vector. From 
that point, I only need access to the const interface of the objects, 
accessible by the various indices.

Thanks for the help,

Jeff