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

Subject: Re: [boost] [interprocess][multi_index] emplace() is not sufficient for maps
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-08-20 11:46:07

Thorsten Ottosen escribió:
> Ion Gaztañaga skrev:
>> Thorsten Ottosen escribió:
>>> 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.
>>>
>>> The situation is characterized by the need to calculate the key after 
>>> the mapped value (a heavy object) has been placed in the pair. To 
>>> calculate the key the mapped value needs to be modified (the key is
>>> calculated as a side-effect).
>>>
>>> I therefore suggest that we add a new function:
>>>
>>>   typedef ... map;
>>>   map m;
>>>   map::node_ptr p = m.get_node_ptr(<like emplace, but only for
>>>                                    constructing the mapped value>);
>>>   p->pair.first = modify( p->pair.second );
>>>   m.insert( boost::move(p) );
>>
>> Is it too expensive to use move insertion from a type with non-const key?
>>
>> //note that key is non-const!
>> std::pair<key_type, value_type> v(/**/);
>>
>> m.insert(boost::move(v));
> 
> Yes, because the mapped object is not fast to move. The way I code 
> around it currently is to allocate all state in an object on the heap. I 
> then do
> 
>   PriorityMap::iterator i = open_.emplace( &nodes_.back() );
>   i->second.swap( newData );
> 
> since swap is now efficient. But it is still not optimally efficient.

Ok, I'll think about it. And you can't implement "move" on top of of 
"swap" to make it efficient (although not optimal, obviously)?

And I'm curious to know why move construction is expensive. Some c-array 
members, maybe?.

Best,

Ion