Re: [boost] [interprocess][multi_index] emplace() is not sufficient for maps

Subject: Re: [boost] [interprocess][multi_index] emplace() is not sufficient for maps
From: joaquin_at_[hidden]
Date: 2009-09-21 04:13:52

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_key

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