This is definitely going to break the container's invariants, yes. Key
modification has to be done via modify() so as to give the container a
chance to reindex elements. So if you are quite sure this is happening
try to remove the offending behavior; after this my bet is that the
invariant assertion will go away. Otherwise please get back here.
Just weighing in here with a related question.
But first to say: I find multi-index to be invaluable. So thanks for a great library.
In my code, the objects I am indexing against are altered elsewhere, and
then my index owning code is notified. At this point, the index owning code
calls:
index.modify( index_iterator, NoOperationFunctor() );
That is, on the assumption that the modify function has no knowledge
of what changes the functor are making, it must re-evaluate all indices.
Therefore, it doesn't matter if the change is made inside the modify function
as long as modify is called.
(So, this statement from above does not appear strictly true:
"Key modification has to be done via modify() so as to give the container a
chance to reindex elements.")
Because (in my case) the change is made elsewhere, I am calling modify with
a functor that does nothing.
In my particular case, I can guarantee that change made elsewhere won't
affect the index that I use to find the iterator to pass to modify.
This may seem a weird scenario, but it also seems weird that I have to call
modify with a no-op functor. Is it possible/desirable to add a simple
update_indices( itor ) function?
Neil