[MultiIndex] how to rebuild index
Hello, What's the most simple way to rebuild an index? If elements change without notifying the container, would iterating from begin to end and calling modify() with no-op - do the job? (I remember there already was such a question, but can't find it.) Thanks.
-----Mensaje original----- De: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] En nombre de Igor R Enviado el: jueves, 23 de febrero de 2012 12:02 Para: boost-users@lists.boost.org Asunto: [Boost-users] [MultiIndex] how to rebuild index
Hello,
What's the most simple way to rebuild an index? If elements change without notifying the container, would iterating from begin to end and calling modify() with no-op - do the job? (I remember there already was such a question, but can't find it.)
Hi Igor, Briefly put, there is no way to do that. The only thing that will work, though it's not officially guaranteed by the implementation, is: * Modify ONE element without using replace() or modify() (by using a const_cast, basically.) * Before doing anything else with the container (except possibly accessing their elements through previously existing iterators and/or advance those iterators around), use modify() with a no-op functor, as you suggest. But you just can't externally (with const_cast) modify a bunch of elements and then get the index to rebuild --the rebuilding machinery assumes that at most one element (the one you call modify() on) is out of place, so if other elements are shuffled as well you'll get some sort of undefined behavior: core dump, whatever. Joaquín M López Muñoz Telefónica Digital Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Briefly put, there is no way to do that. The only thing that will work, though it's not officially guaranteed by the implementation, is:
* Modify ONE element without using replace() or modify() (by using a const_cast, basically.) * Before doing anything else with the container (except possibly accessing their elements through previously existing iterators and/or advance those iterators around), use modify() with a no-op functor, as you suggest.
I see... Unfortunately, it doesn't fit my use-case. I store weak_ptr's, and my key extractors have to return different results for expired and non-expired weak_ptr's.
But you just can't externally (with const_cast) modify a bunch of elements and then get the index to rebuild --the rebuilding machinery assumes that at most one element (the one you call modify() on) is out of place, so if other elements are shuffled as well you'll get some sort of undefined behavior: core dump, whatever.
What if I just copy all the elements to another container of the same type? Will the iteration from begin() from end() work correctly?
Igor R <boost.lists <at> gmail.com> writes:
But you just can't externally (with const_cast) modify a bunch of elements and then get the index to rebuild --the rebuilding machinery assumes that at most one element (the one you call modify() on) is out of place, so if other elements are shuffled as well you'll get some sort of undefined behavior: core dump, whatever.
What if I just copy all the elements to another container of the same type? Will the iteration from begin() from end() work correctly?
I think this might work (I suggest you try it.) Remember that the source container is in an invalid internal state (by altering the elements keys you've broken the container invariants), so after doing the copy you should destroy it immediately. Again, all of this is strictly undocumented stuff. No guarantee any of this will work in the event, say, of a library upgrade. Maybe some reformulation of your data design can allow you to do what you want while remaining in the shiny world of legal behavior. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Igor R -
JOAQUIN M. LOPEZ MUÑOZ -
Joaquín M López Muñoz