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 < boost@lists.boost.org> 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_stru... 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... 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