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: Chris Glover (c.d.glover_at_[hidden])
Date: 2015-03-13 11:42:58

>
> Ion Gaztañaga wrote:
> > El 13/03/2015 a las 14:38, Phil Endecott escribió:
> >
> > > (Personally, I have a flat_map that does batched insertions i.e. the
> new
> > > items are appended individually and then merged at the end of the
> batch.
>
> On Fri, 13 Mar 2015 at 11:04 Peter Dimov <lists_at_[hidden]> wrote:
> It doesn't have to have an interface, at least in principle. flat_map can
> just append the new elements to the end, keeping them sorted, until it hits
> a threshold, then merge. Lookups will first look at the new element range
> (because those are likely to be in cache), if not found, at the old element
> range.
>
>

It's possible to accomplish this today, but you need to do the buffering
yourself outside of the flat_map using the ordered_unique_range_t insert
method.

http://www.boost.org/doc/libs/1_57_0/doc/html/boost/container/flat_map.html#idp36621984-bb

I use this method a lot where I figure out what I am going to be inserting
before I do the insert, then I insert in one step.  Of course, this assumes
you don't need to know what's in the map while you're also figuring out
what to put in the map.

-- chris