Ion Gaztañaga skrev:
Thorsten Ottosen escribió:
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.
For keys where assignment don't throw, we get the strong guarantee. For the case where assignment could throw, I agree the element should be erase (the user can then reinsert manually if that happens). So maybe we should return pair<iterator,bool> to tell the user if the update succeeded? For cases where the ordering is based merely on a non-throwing part of the Key type, it could be usable with template< class Key2 > iterator modify_key( const_iterator element, const Key2& new_key ); This function would place the existing node in its right place, but not change the key object which the user then has to do, e.g. iterator i = modify_key( x, new_object.sub_object ); i->swap( new_object ); I guess there are some additional overloads for movable types. -Thorsten