
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
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