[Boost-users] [multi_index] modify_key with an iterator to composite_key

Hi,

From what I've found on the net (here: http://groups.google.com/group/boost-list/browse_thread/thread/687ce9662a4c1...), about this problem, Joaquin explains that modify_key on a composite_key isn't supported.

Relevant part from that thread is: When you use modify_key, you modifier functor is passed

*the key* rather than the whole element as is the case with modify. In this particular situation, the key is a composite key; so the key object (defined privately by composite_key) is some entity that somehow references entry::m_x and entry::m_y. This object is not exposed to the public and you're not supposed to try to use it or modify it, hence the problems you're seeing. In short, when using composite_key you cannot use modify_key.

The alternative must be to use modify() instead, so I'd like to know how to get the best performance in the following scenario: My index is specified as. namespace bmi = boost::multi_index; struct Index : boost::mpl::vector2 < bmi::hashed_unique

, bmi::ordered_non_unique < bmi::composite_key < Entry, bmi::member, bmi::member > > > {};

I frequently updated Entry::m_State and Entry::m_Timestamp, but never Entry::m_Name during the lifetime of an entry, thus I expected modify_key to be faster since the expensive hash index don't need to be updated. Since I cannot tell modify() which parts of the Entry I'm about to update, I don't see how I can avoid the rehashing. Maybe there's a better way to configure the index? I'm using Entry::m_State for an equal_range() search, while Entry::m_Timestamp is only for ordering (I bump the timestamp everytime I change m_State). I am using boost.1.35 btw Any response much appreciated, Christian