Ion Gaztañaga escribió:
Thorsten Ottosen escribió:
Thorsten Ottosen skrev:
Hi Ion and Joaquín,
This issue is related to node-based containers. I think you both have added emplace() to provide efficient in-place construction.
However, I often encounter a situation where emplace() is not sufficient for me.
I actually got into a situation where I need another member function. The issue arises when I use map/set as a priority_queue and want to limit the size of the queue. In this situation I will be erasing one element and inserting one element again and again. Unless the map/set keeps a free-list of previously erased elements (which I don't think they do normally) we will be deallocating and allocating a new node over and over again.
Therefore I would like to see the follwing member:
iterator modify_key( const_iterator element, const Key& new_key );
This function only needs to rebalance/resort the keys and can completely avoid deallocation/allocation.
Interesting. What about exception safety? We can't assure strong guarantee. It could just erase the element if the change fails? We could also use the assignment operator instead of destroy+construct to reuse some resources
I think this is basically covered by the modify_key overloads provided by Boost.MultiIndex ordered indices: http://www.boost.org/libs/multi_index/doc/reference/ord_indices.html#modify_... Taka a look at the exception safety guarantees and the behavior if the new key clashes with a preexisting one (briefly put, this results in deletion of the element, except if the user provides a rollback functor). The interface is a little more abstract than Thorsten's proposal, since we accept a generic key modifier rather than a new key. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo