2016-12-14 13:06:05 UTC
I have a question concerning the automatic re-indexing of
Is it somehow possible to modify a member of the element-type that is
used as key for (another) index without triggering automatic
re-indexing? (Of course, I want to be able to trigger manual re-indexing
Or is it at least possible to adjust the code so that this can be achieved?
To understand my question, here is my use-case and why I need it.
I have a boost::multi_index_container with multiple indexes (one
hashed_unique and four hashed_non_unique).
I am accessing a range of elements through a hashed_non_unique index
'A'. Then I am iterating through these elements and want to modify the
value of a member 'M' of each element. However, that member is used when
calculating the key for another hashed_non_unique index 'B'.
Therefore, I must use the "modify" function of index 'A'.
The problem is now that it takes forever to modify the entire range. (We
are talking about 100 thousands if not millions of entries that need to
Probably because re-indexing is triggered after each call to "modify".
However, in my case it should be perfectly fine to postpone the
re-indexing after I modified the entire range, because I am not going to
access any element through index 'B' until I finished modifying the
As a workaround I removed index 'B' from the container and declared the
element-member 'M' as mutable. This allows me to directly change the
value of 'M'.
The speedup is astonishing. It now finishes almost in no time.
But this workaround is not really feasible as it requires reimplementing
index 'B' by somehow tracking the information outside of the
Therefore, my question really is:
Is it possible to provide an "unsafe_modify" function, which does the
same as "modify" but does not trigger automatic re-indexing, and an
"refresh_index" function, which (manually) triggers the re-indexing?