[container] New container proposal: boost::container::hub, request for endorsement
Hi, I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance: https://github.com/joaquintides/hub/blob/develop/README.md#performance (The reason I didn't name it "hive" is because hub is not 100% conformant to std::hive spec, details at the repo linked above.) Is there interest in having this in Boost? If so, please endorse the submission! As the codebase is fairly small (single 1800-LOC header), and due to the subject matter, my inclination is to propose it as part of Boost.Container rather than as a separate library. Happy to discuss this proposal and its technical details. Looking forward to your feedback. Best, Joaquín M López Muñoz
Joaquin M López Muñoz wrote:
Hi,
I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance:
https://github.com/joaquintides/hub/blob/develop/README.md#performance
(The reason I didn't name it "hive" is because hub is not 100% conformant to std::hive spec, details at the repo linked above.)
Is there interest in having this in Boost? If so, please endorse the submission! As the codebase is fairly small (single 1800-LOC header), and due to the subject matter, my inclination is to propose it as part of Boost.Container rather than as a separate library.
I endorse this proposal. I'm not sure whether separate or part of Boost.Container would be better.
On Sun, Feb 1, 2026 at 3:18 PM Joaquin M López Muñoz wrote:
I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance: [...]
Is there interest in having this in Boost? If so, please endorse the submission!
I endorse the proposal. I'd also like to see how it performs compared to the SegmentedTree container that was proposed for Boost, not long before Hive was: https://det.github.io/segmented_tree/boost_segmentedtree/performance.html Thanks, Glen
El 01/02/2026 a las 21:33, Glen Fernandes escribió:
On Sun, Feb 1, 2026 at 3:18 PM Joaquin M López Muñoz wrote:
I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance: [...] Is there interest in having this in Boost? If so, please endorse the submission! I endorse the proposal.
I'd also like to see how it performs compared to the SegmentedTree container that was proposed for Boost, not long before Hive was: https://det.github.io/segmented_tree/boost_segmentedtree/performance.html
Yes, I can do that comparison. I'll be quite busy the next weeks so it will take a bit, thanks in advance for your patience. Joaquín M López Muñoz
El 01/02/2026 a las 21:16, Joaquin M López Muñoz via Boost escribió:
Hi,
I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance:
https://github.com/joaquintides/hub/blob/develop/README.md#performance
(The reason I didn't name it "hive" is because hub is not 100% conformant to std::hive spec, details at the repo linked above.)
Is there interest in having this in Boost? If so, please endorse the submission! As the codebase is fairly small (single 1800-LOC header), and due to the subject matter, my inclination is to propose it as part of Boost.Container rather than as a separate library.
Happy to discuss this proposal and its technical details. Looking forward to your feedback.
I endorse the proposal. The fact that is different from std::hive but more potentially more performant, it's IMHO a good reason to have and maintain it inside Boost, as it won't be obsolete or deprecated once std::hive is available in all mayor C++ standard libraries. Since this is a small proposal, I can serve as review manager if needed. For obvious reasons, I will abstain in the Boost.Container vs separate library opinions/decision. Best, Ion
Ion Gaztañaga wrote:
Since this is a small proposal, I can serve as review manager if needed. For obvious reasons, I will abstain in the Boost.Container vs separate library opinions/decision.
Why? Your bias (assuming one exists at all) does not preclude you from expressing an opinion, or justifying it.
On 2 Feb 2026 14:26, Peter Dimov via Boost wrote:
Ion Gaztañaga wrote:
Since this is a small proposal, I can serve as review manager if needed. For obvious reasons, I will abstain in the Boost.Container vs separate library opinions/decision.
Why? Your bias (assuming one exists at all) does not preclude you from expressing an opinion, or justifying it.
I would even say that Ion's opinion should be key in this matter, given that Ion is the (sole?) maintainer of Boost.Container and must have a say in what goes into his library.
El 02/02/2026 a las 13:12, Andrey Semashev via Boost escribió:
On 2 Feb 2026 14:26, Peter Dimov via Boost wrote:
Ion Gaztañaga wrote:
Since this is a small proposal, I can serve as review manager if needed. For obvious reasons, I will abstain in the Boost.Container vs separate library opinions/decision.
Why? Your bias (assuming one exists at all) does not preclude you from expressing an opinion, or justifying it.
I would even say that Ion's opinion should be key in this matter, given that Ion is the (sole?) maintainer of Boost.Container and must have a say in what goes into his library.
Good point ;-) Ion
I am endorsing on the following grounds. - Concepts like Containers and Data Structures are easy to grasp (unlike open-methods haha), and typically self-contained. They make a good "front of the window product" to appeal to new putative Boost users. - It's good to have an implementation before a feature makes it into the standard. It's even better to have two. Competition good! Helping the standard move in the right direction is a historic mission of Boost. - Joaquín has an excellent record on container libraries. J-L On Sun, Feb 1, 2026 at 3:18 PM Joaquin M López Muñoz via Boost <boost@lists.boost.org> wrote:
Hi,
I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance:
https://github.com/joaquintides/hub/blob/develop/README.md#performance
(The reason I didn't name it "hive" is because hub is not 100% conformant to std::hive spec, details at the repo linked above.)
Is there interest in having this in Boost? If so, please endorse the submission! As the codebase is fairly small (single 1800-LOC header), and due to the subject matter, my inclination is to propose it as part of Boost.Container rather than as a separate library.
Happy to discuss this proposal and its technical details. Looking forward to your feedback.
Best,
Joaquín M López Muñoz
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/6YXMHMAR...
Hi,
I've been writing and benchmarking (candidate) boost::container::hub, a nearly drop-in replacement of C++26 std::hive that has excellent performance:
https://github.com/joaquintides/hub/blob/develop/README.md#performance
Given the receipt of several endorsements I have spoken with Joaquín and Ion (review manager) for scheduling this review. We decided on 16-26 April, which will be reflected on the calendar shortly. Thank you in advance for your participation. Matt
participants (7)
-
Andrey Semashev -
Glen Fernandes -
Ion Gaztañaga -
Jean-Louis Leroy -
Joaquin M López Muñoz -
Matt Borland -
Peter Dimov