Re: [Boost-users] [multi_index] function to force to recreate indexes?

Boris ha escrito:

On Wed, 21 Feb 2007 23:17:28 +0200, JOAQUIN LOPEZ MU?Z wrote:

...

[...]At the end of the day, the problem is not whether we can have a reliable implementation of refresh(): you enter into the realm of undefined behavior once you modify an element externally to the container. By the time you are to call refresh(), you have already performed an illegal action.

Thanks for all your explanations! They will help me definitly to build a more robust program around multi_index_container.

If I understand you correctly it all comes down to what is explained in the documentation anyway: Use replace() and not modify() if you want to be safe?

Umm, no, sorry, I think I haven't explained myself clearly... Both replace() and modify() are safe if used correctly --the difference is that replace() keeps the original content if the modification is incompatible with the uniqueness constraints of the container. What I'm referring to is: consider the following piece of code: typedef multi_index_container< shared_ptr<int>, indexed_by<...>

mic_t; ... mic_t m; m.insert(shared_ptr<int>(new int(0))); mic_t::iterator it=m.begin(); **it=3; // A m.modify(it,null_modifier()); // B

OK, this exemplifies the "resync" trick we were discussing a couple of posts ago. Although this works in practice, the problem is that line A is *illegal* as far as the semantics of Boost.MultiIndex (or STL associative containers for that matter) go: you are not allowed to externally modify an element if such modification results in a violation of the container invariant, namely that the elements are kept in ascending order. So, although //B restores the invariant, strictly speaking the code is illegal because of //A. When both //B is executed right after //A you are in practical terms safe, but *only* in practical terms, the formal specification of Boost.MultiIndex does not accept the sequence //A,//B as a valid operation. If the null_modifier trick is illegal but safe in practice, going further than that --doing massive external modifications-- is equally illegal and besides highly dangerous, that's why it's sensible not to consider a refresh() function that would in principle ratify massive external modifications. The subject is a little tricky as it deals with safety in practical and theoretical terms, so if anything's still not clear enough please do not hesitate to come back to me. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo