Re: [boost] [containers] Are there flat_map/set and stable_vector proposals at work?

Subject: Re: [boost] [containers] Are there flat_map/set and stable_vector proposals at work?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-11-09 10:37:21

On Sun, Oct 27, 2013 at 1:35 PM, Jonathan Wakely
<jwakely.boost_at_[hidden]>wrote:

> No proposal has reached WG21, I can't say whether anyone is working on one.
>
>
Ok.

> I'm against the idea that every useful container needs to be in the
> standard, if you want a different set of trade-offs from the standard
> containers then use different containers, either from Boost, another
> library, or write your own.
>
>
I think I would have have the advice for most non-standard containers, but
I strongly disagree in the case of flat_set, flat_map and stable_vector.
The standard containers don't provide enough basic alternatives and, at
least in my experience and experiences I've read online and discussed with
other C++ devs,
we end-up often getting back to std::vector for almost anything.
Boost's flat_set and flat_map are preferable as default container than
std::set/map in almost all cases I've been working on in the last 5 years
(which include time I couldn't use these containers
in practice). My understanding of the standard is that it should provide
useful and widely used tools, like containers, which are then standard
because everybody should use them
by default.

Adding these containers (stable_vector being discutable but I find it
extremely useful too) in the standard library would, in my opinion,
be a huge improvement both for performance vs simplicity  reasons and for
ease of education and choice: it's far simpler to just use
something that is fundamentally a vector in all cases, but with the
interface corresponding to the wanted manipulations, than to have to know
the (wide and long to explain) differences between contiguous and
node-based containers.

Maybe I'm a bit biased by my specific projects, but they are of wide
variety and I end up very often choosing flat_map/set instead of
std::map/set
simply because cases where it flat_* are what I really want occurs far more
often than cases where std::set/map are what I really want.

It looks like I'm not the only one praising these kind of containers:
http://www.slashslash.info/2013/10/ode-to-a-flat-set/

At the time I'm writting this I'm not in the position to start working on a
proposal, even if I'm really tempted (I also think I'm not a specialist so
maybe I'm not legitimate for this).
But I'm considering doing it in coming months when I'm done with other
things.