Hi,

From what I've found on the net (here: http://groups.google.com/group/boost-list/browse_thread/thread/687ce9662a4c1c68?pli=1), 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::member<Entry, std::string, &Entry::m_Name> >,
        bmi::ordered_non_unique
        <
            bmi::composite_key
            <
                Entry,
                bmi::member<Entry, int, &Entry::m_State>,
                bmi::member<Entry, int, &Entry::m_Timestamp>
            >
        >
    >
    {};

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