Jeff Flinn ha escrito:
JOAQUIN LOPEZ MU?Z wrote:
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?
I'm not sure if you mean this, but modifying a part of an object from which no
key extractor depends results in no repositioning. For instance
struct element{
int x,y,z
};
typedef multi_index_container<
element,
indexed_by<
ordered_unique
multi_index_t;
modifying element::z in the example above does not cause repositioning ever. Is this what you were referring to?
// 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?
No, to provide such functionality just replace the occurences of .modify(...) with .modify_key(...);
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.
I agree with you it's probably simpler to have an intermediate vector and dump to the multi-index container after full loading --working directly with the multi-index container is probably slower and can pose very difficult problems: for instance, if you have a unique index it might not be possible to insert several elements for which their unique key have not yet arrived from the data stream. Good luck with your project, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo