Boost logo

Boost Users :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-11-28 06:56:17


Hello Jeffrey,

Jeffrey Holle ha escrito:

> I'm using boost version 1.33.1 and am contemplating using a multiIndex
> container in my application.
>
> The held object will be something like:
>
> class element {
> int x;
> int y;
> Object *pObject;
> };
>
> I need 2 ordered_non_unique indices using x and y and one ordered_unique
> index on pObject.
>
> The problem is that the values of x and y will need to be modified
> during the life of this container. Since the documentation says these
> indices are implemented using red-black trees, I think I'm heading for
> trouble.

No, B.MI is designed to handle these situations :)

> However, the multiIndex container seems to have a "modify_key" method.
> I can guarantee that the pObject value will not change, so if I obtain
> an iterator to an element based on this index, will I be able to modify
> either x or y and expect their related indices to still work?

B.MI provides updating mechanisms that take care of all the necessary
index internal rearrangement resulting from modifications on the keys:

  modify()
  modify_key()
  replace()

In your particular case, if the iterator belongs to the pObject-index,
modify_key is of no use, since the key here is precisely pObject, which
you do not wish to update. You can use then modify(), with accept a
modifying functor to be passed a reference to the whole element, or
also replace(), wich is passed a new element object to substitute for
the old one. In any case, the indices are internally kept in sync.

Please find attached a small snippet showing the various ways you
can use the updating facilities of B.MI, both with user-defined
modifying functors and by means of the Boost Lambda library. If
you have further doubts, don't hesitate to ask.

HTH,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo




Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net