April 2026 - Boost-announce

[review] [hub] Review result: ACCEPTED
by Ion Gaztañaga 28 Apr '26

28 Apr '26

Hi to all, I'm glad to announce that the proposed boost::container::hub container has been ACCEPTED. Congrats Joaquín! I'll try to summarize the comments/actions/changes/suggestions from reviewers. We have received 6 reviews: - Andrzej Krzemienski: Accept — "I recommend accepting Hub into Boost." - Amlal El Mahrouss: ACCEPT — merge into container. - Arnaud Becheler: ACCEPT — "I suggest: ACCEPT." - Christian Mazakas: ACCEPT — "strongly Accept" into Container. - Matt Borland: ACCEPT — explicit closing vote. - Emil Dotchevski: ACCEPT — "My vote: ACCEPT" (with a list of issues). - Peter Turcan: (documentation comments; no explicit ballot line) ------------------- Andrzej Krzemienski ------------------- Praises: - Easy to read and understand - Well documented, where needed. Main comments: - Recommends making the `visit` functions free functions and renaming them to `for_each` and `for_each_while` --> Joaquín agrees - std::hive and hub are not SequenceContainers, docs should make this explicit --> Joaquín agrees. - Questions BOOST_LIKELY --> Joaquín clarified BOOST_LIKELY is not the core performance story. - "memory()" is marked with "// TODO: remove;" --> Joaquín agrees to remove it. - Reported a GCC -Wall warning when sorting an empty hub (Peter Dimov flagged it as a false positive and suggested a fix) --> Joaquín agrees to fix this. ----------------- Amlal El Mahrouss ----------------- Amlal praises several aspects of the library: - Preconditions - Usage of known requirements (like CopyInsertable) - Free functions - NATVIS for MSVC - Implementation readability - BOOST_CONTAINER_HUB_PREFETCH transparency ------------ Matt Borland ------------ Points to: - Strong design decisions and clear deviations from std::hive - Usefulness is clear given std::hive in C++26; on testing - Clean implementation - Appreciates pretty printers Suggestions: - Stricter warnings (-Wall, -Werror, -Wold-style-cast) --> Joaquín will tighten the warnings - Questions MSVC minimum (14.3) vs very old GCC/Clang --> Joaquín will try to handle that with the help of Boost.CI - Finds ASCII performance tables hard to read, suggests implementing Peter Turcan-style improvements. - Reports 4 of 5 tests failed on ARM Mac with Clang 22 / GCC 15 --> PRs reported, one liner fix --> Joaquín will fix it and will improve the regression with the help of the latest Boost.CI improvements. --------------- Arnaud Becheler --------------- Praises: - C++11 portability - Benchmarks - Code looks clear - Docs Comments about docs that Joaquín will address: - trim_capacity example needs clarity - "Pointers and iterators to an element" section needs improvement - motivation could use a clearer competitor comparison - prefers comparative tables; ASCII tables are awkward (Joaquín clarifies final docs will not stay Markdown) - get_iterator needs a motivating story for users who only have T* (Joaquín admits uncertainty on real-world value of get_iterator beyond standard API parity) - Typos and line-break nits ----------------- Christian Mazakas ----------------- - General agreeement. - Minor caution that insertion order is not preserved when slots are reused, should be stated in the docs Christian also suggets a future extension for slotmap-style alternative. Joaquín agrees to review this suggestion in the future and also points to a proposal for a "reserving" (virtual memory) allocator idea as future exploration. ----------------- Emil Dotchevski ----------------- Likes: - The bitmask approach vs hive. - Very high quality implementation Notes/suggestions: - We should leave block size unspecified in documentation and removing explicit "64" in docs. - Possible leaks in constructors if block_list lacks cleanup (Joaquín clarified it's not the case) - sort_iterator::operator[] and operator* --> Joaquín will fix it - transfer_sort buffer and over-alignment --> over-aligned new[] will be used where available. - exception guarantee text for transfer_sort should say basic guarantee - get_iterator should assert validity Joaquín also said that he will add exception-safety tests. ------------ Peter Turcan ------------ Peter focused on clarity and adoption improvements: - Opening sentence and HFT acronym (should be clarified) --> Joaquín will revise intro - Deeper, less conversational use-case treatment - Explain the role of 64 and why it is not freely tunable --> Joaquín agrees (also comments 128 would be nicer if hardware had a single instruction) - Prefer plain-English comments - Clarify trim_capacity / reserve comments --> OK - Avoid excessive brackets on the performance section and clarify some numbers there --> OK - Reference could use more exception / example cross-links --> OK ------------ ------------ Joaquín is already working on changes based on the review feedback here: https://github.com/joaquintides/hub/tree/feature/review-feedback I will work with Joaquín to find the best way to integrate code/docs/tests into Boost.Container. Best, Ion

1 0

[release] Boost 1.91.0 released
by Marshall Clow 22 Apr '26

22 Apr '26

Release 1.91.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. The release contains one new library: * Decimal: An implementation of IEEE754 Decimal Floating Point Numbers, from Matt Borland and Christopher Kormanyos. as well as numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.91.0> You can also download directly from: <https://archives.boost.io/release/1.91.0/source/> To install this release on your system, see <https://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes, Ion Gaztañaga

1 0

[review] The review of boost::container::hub starts! April 16 - April 26
by Ion Gaztañaga 15 Apr '26

15 Apr '26

Dear users and members of Boost, I'm proud to announce that the formal review of Joaquín M López Muñoz's boost::container::hub container, for inclusion in the Boost.Container library, starts today ( in my timezone ;-) ), April 16, and runs through April 26. It may be downloaded from https://github.com/joaquintides/hub and the documentation may be found here: https://github.com/joaquintides/hub/blob/develop/README.md Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ boost::container::hub is a sequence container with O(1) insertion and erasure and element stability: pointers/iterators to an element remain valid as long as the element is not erased. boost::container::hub is very similar but not entirely equivalent to C++26 std::hive (hence the different naming, consult the section "Comparison with std::hive", for details): https://github.com/joaquintides/hub/blob/develop/README.md#comparison-with-… boost::container::hub has excellent performance, you can see some benchmarks here: https://github.com/joaquintides/hub/blob/develop/README.md#performance Basic example: #include <boost/container/hub.hpp> #include <cassert> int main() { boost::container::hub<int> h; // Insert some elements and keep an iterator to one of them for(int i = 0; i < 100; ++i) h.insert(i); auto it = h.insert(100); for(int i = 101; i < 200; ++i) h.insert(i); // Erase some of the elements erase_if(h, [](int x) { return x % 2 != 0;}); assert(*it = 100); // iterator still valid // Insert many more elements for(int i = 200; i < 10000; ++i) h.insert(i); assert(*it = 100); // iterator still valid } An important tradeoff when using boost::container::hub is the fact that the user can't control the position where a new element will be inserted: boost::container::hub reuses the memory addresses of previously erased elements to maximize performance and keep the data structure as compact as possible. The primary use case for boost::container::hub is in high-performance scenarios where elements are created and destroyed frequently, insertion order is not relevant and pointer/iterator stability is required: game entity systems, particle simulation, HFT... For more information, see the Tutorial section: https://github.com/joaquintides/hub/blob/develop/README.md#tutorial Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost component. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? (Note that, if accepted, final documentation will be included in Boost.Container docs, so please review the content, not the format) - What is your evaluation of its potential usefulness? - Did you try to use the container? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards, Ion Gaztañaga, Review manager

1 0

[review] [hub] boost::container::hub review starts on April 16
by Ion Gaztañaga 04 Apr '26

04 Apr '26

Dear Boost community, The formal review of Joaquín M. López Muñoz's boost::container::hub container is scheduled for April 16 - April 26. Hub is 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 codebase is fairly small (single 1800-LOC header), and due to the subject matter, it is proposed to be part of Boost.Container rather than as a separate library. You can find code and documentation here: https://github.com/joaquintides/hub Best, Ion

1 0