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. - Christian