Christian Holmquist escribió:
On the bright side, index updating has been implemented so as to be as fast as possible: before relocating an element indices check internally whether the element remains in place after modification, which is usually a cheaper operation than brute relocation. In the particular case of a hashed index, if modify() hasn't touched its key then updating merely invokes a hash call and a couple of pointer comparisons (not even equality comparison is needed.)
Excellent, this is definitely good enough. Will I gain anything by choosing hashed_non_unique over hashed_unique in this case? Outer code guarantees that duplicates won't be inserted anyway, so this constraint is implicit in my case.
hashed_unique should be marginally better, but again you'd better profile that assumption. Thanks for using Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo