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

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.

- Christian
_______________________________________________
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/SJKBIE62BYNQWAFYT4NL56KFOV42THCP/