Re: [boost] [flat_map] Any interest in a flat_map variant that is much faster on insertion/erase at the price of a slower lookup?

Subject: Re: [boost] [flat_map] Any interest in a flat_map variant that is much faster on insertion/erase at the price of a slower lookup?
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2015-03-14 09:10:14

Peter Dimov wrote:
> Phil Endecott wrote:
>
>> I think we discussed this before.  My preferred approach is
>> 
>> flat_set S;
>> {
>>    flat_set::batch b(S);
>>    b.insert(xxx);
>>    b.insert(yyy);
>> }  // b's dtor does the merge
>
> What do you do when b.insert(yyy) throws?

You have at least a couple of choices, e.g. the dtor merges
the successfully-inserted values or it discards everything.

Of course the next question is whether either merging or
discarding can also throw.  I would hope that discarding
(i.e. truncating the vector back to its original size)
could reasonably be expected never to throw, right?
Merging would require that the comparisons cannot throw.

Regards,  Phil.