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

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-03-16 12:53:26

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<member<element,int,&element::x>,
    ordered_non_unique<member<element,int,&element::y>,
  >
> 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