The details of that implementation are the opposite of what I was trying to
advocate for. slot_map uses sparse paged allocation with stable pointers
the same way std::hive does. My arguments about high frequency iteration
over std::hive apply the same w.r.t. slot_map. I would like a dense
non-paged array of values and the ability for references held by other
languages to be broken without RAII. I also proposed a 40-50 bit "generation"
counter (even on 32-bits as compared to 10) before the handle id wraps.
That is far larger than slot_map as I didn't want to be responsible for
causing data corruption at scale.

In my mind the question is as much about the kind of language C++ is trying
to be. I have been "writing the world from scratch" in C++ for 20 years.
And maybe we like it that way. Other languages offer you a soup to nuts
experience and all I would be doing right now is submitting a pull request
on GitHub to get this merged.

In this case I am talking about 400 LOC so far so I can easily add the code
to gcc and clang. Standardization would be more work. Its cool if there is
no appetite for more containers.



On Mon, Jul 13, 2026 at 6:01 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> On Mon, Jul 13, 2026 at 7:55 PM A Johnston via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> 1. Hello Std Proposals,
>>
>>
>> I would like to show the list the kind of data structure I have used in
>> real-time contexts where std::hive is also recommended. [...]
>>
>> The handle_map is a mapping from a 64-bit handle to a templated value
>> type. The handle_map uses a single array for the handle table (and other
>> accounting) and a single contiguous array of values for the value array.
>>
>
> I haven't looked closely at your code, but this sounds an awful lot like
> the well-known(?) data structure also known as "slot_map".
> If so, there's another implementation here:—
> https://github.com/Quuxplusone/sg14#slot_map-future--c14
> https://github.com/Quuxplusone/SG14/blob/master/include/sg14/slot_map.h
> and a corresponding proposal (Allan Deutsch, June 2017) here:—
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0661r0.pdf
>
> The proposal P0661 never went anywhere. (It was seen by LEWG in Toronto,
> July 2017; got an 11–4–1–0–0 encouragement for "more work"; and nothing
> happened after that AFAIK.)
>
> I'm very skeptical that slot_map belongs in the paper standard, for all
> the same reasons that std::hive itself doesn't belong in the paper
> standard. Anyone who knows what the thing *is*, will probably be able to
> implement a better version of it than their STL vendor can implement. (See
> also: std::deque; std::priority_queue; std::flat_map.) I do think it's nice
> to have a battle-tested reference implementation (e.g. in Boost; I *don't*
> claim that the "SG14" repository I maintain counts as "battle-tested"
> enough) that people can consult as prior art for naming and stuff like
> that, but (1) I don't think we need *three* reference implementations,
> and (2) I don't think we want *any* of our three STL vendors burdened
> with creating those reference implementations.
>
> –Arthur
>