Re: [review] The review of boost::container::hub starts! April 16 - April 26

El 21/04/2026 a las 0:32, Christian Mazakas via Boost escribió:
> On Sun, Apr 19, 2026 at 1:38 PM Andrey Semashev via Boost <
> [email protected]> wrote:
>
>> This is solved by adding a new target to Boost.Container CMakeLists.txt,
>> e.g. `Boost::container_header_only` for the header-only bits. I would
>> argue, this would be useful regardless of `hub` being part of
>> Boost.Container. Some other libraries already provide more lightweight
>> targets where a full dependency would be too expensive for users.
>>
> If Ion is okay with this, then I have no problems at all with Hub being in
> Container.
>
> Otherwise, what else is there to really say? Joaquin is a long-time veteran
> Boost author contributing Yet Another Container.
>
> I can safely vote that we strongly Accept this library for inclusion into
> Container.
>
> I think certain things will, by their nature, maybe be surprising to users
> unfamiliar with the container like insertion order not being preserved as
> old slots are reused.
>
> But I gave the docs a cursory once-over and I couldn't find any glaring
> issues.
>
> Interestingly, this makes me wonder if maybe we could use a proper slotmap
> implementation as well, i.e. instead of a linked list of fixed blocks, a
> single contiguous block that uses a freelist internally. Obviously this
> design would invalidate iterators on resize but if a user simply stored
> indices into the slotmap, it could be made to work pretty well, I think.

Thanks Christian for your review! It'd be fairly straightforward (I 
think) to implement a slot map using the same underlying structure as 
boost::container::hub:

https://raw.githubusercontent.com/joaquintides/hub/develop/doc/img/data_structure.png

except that elements all lie in a contiguous array. Writing down in my 
todo list to prototype that and benchmark against boost::container::hub; 
from a purely theoretical analysis, slotmap should lose on insertions 
(because of reallocation) and win on iteration (because of cache locality).

On a related note, some weeks ago an author came on reddit with an 
interesting design:

https://www.reddit.com/r/cpp/comments/1sbro26/a_fast_contiguous_windows_slot_map_implementation/

The interesting part is that memory chunks are allocated _contiguously_ 
by reserving the maximum possible size in memory via Win32 VirtualAlloc 
--downside, among others, is the user has to specify the maximum 
possible size in advance. This reserve/commit scheme can't be served by 
C++ allocator API, but maybe a reserving_allocator concept or something 
could be designed to abstract the pattern. I'll play with this when I 
have the time.


Joaquín M López Muñoz

_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/MDMTIYSXWCLXDLFM6DTDO35O2MG4JSM4/