April 2026 - Boost - lists.boost.org

Seeking Endorsement: Boost.int128
by Matt Borland 30 Apr '26

30 Apr '26

Dear All, I am seeking endorsement for review of my library int128 [1]. The library requires only C++14, is header only, and has no mandatory dependencies. What does int128 provide? Two portable and performant types: a 128-bit signed integer and a 128-bit unsigned integer, as well as a standard library for them. The performance of these types have been tuned and tested on a variety of architectures to include: x64, x32, s390x, ARM64, ARM32, PPC64LE. Both of the types and most of their library functions also work inside CUDA kernels. Benchmarks against Boost.Multiprecision, Absl, MSVC's software 128-bit integers, and built-ins, are available [2]. A couple of questions that I anticipate: Why do we need this if we already have Boost.Multiprecision? An old compliant against Boost.Multiprecision is that the 128-bit integer types are not 16 bytes [3]. The 128-bit integer types are also incident to the arbitrary precision type rather than a dedicated implementation. This allows int128 to improve performance in places that Multiprecision can't or shouldn't which is reflected in the benchmarks [2]. Should this go in Core (or other existing lib)? I talked with Peter about this a while back, but int128 was already getting too big at the time. Now int128's include/ directory has a higher sloccount than core's, so it makes even less sense. I would rather it not go into Multiprecision, as int128 would have a module weight of up to 5 (optional dependencies), whereas Multiprecision has a module weight of 25 [4]. The design is fundamentally different than the types used in Multiprecision as well (All types are backends into a master template called number for compatibility) Why does the library have a low number of stars? This library started life as the backend for Boost.Decimal since we needed a cross platform 128-bit integer for the representation of decimal128_t as well as to perform fundamental operations with decimal64_t. You can still find a int128/ folder in Decimal that will be removed if this lib is accepted (it's a vendored version of the library now). I find these types useful for my own purposes, so I expect others will too. Please let me know if you have any questions as you take a look at the library. Thanks for your time, Matt [1] https://github.com/cppalliance/int128 [2] https://develop.int128.cpp.al/u128_benchmarks.html [3] https://stackoverflow.com/questions/41876253/boostmultiprecisionuint128-t-s… [4] https://pdimov.github.io/boostdep-report/develop/module-weights.html

13 46

std::core_dump() Newsletter Moving to Quarterly
by Mark Cooper 30 Apr '26

30 Apr '26

Hey, quick update on std::core_dump(): We're moving to a quarterly publishing schedule for the foreseeable future. The team is deep in a number of other initiatives and we need to prioritize accordingly. We'll be reaching out in late June to gather suggestions and content for the July issue. Thanks!

1 0

Corosio, Capy Review Manager
by Vinnie Falco 29 Apr '26

29 Apr '26

As some may remember, Jeff Garland was the review manager for Boost.Asio some twenty or so years ago. I have asked Jeff to reprise the role for Corosio, and he has accepted. Ideally the review period would end before the mid-year Boost release, yet that puts significant scheduling pressure on WG21 attendees who are planning to go to Brno. Therefore I will leave it to Jeff to decide what time works best. Thanks

3 4

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

29 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

2 1

[review] Reminder: The review of boost::container::hub ends April 26
by Ion Gaztañaga 27 Apr '26

27 Apr '26

Dear all, A kind reminder, hub's review will end soon. Please consider taking a bit of time to review this interesting container ;-) The proposal is small enough anyone can review it and it might be useful for many people! 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 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 Waiting you reviews! Best, Ion (Review Manager)

5 5

[review] The review of boost::container::hub is finished
by Ion Gaztañaga 27 Apr '26

27 Apr '26

Hi, Thanks to all that have participated in the review. I'll collect all the relevant comments and publishing the result in the following days. Best, Ion (Review Manager)

1 0

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

25 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

11 23

[hub] Andrzej's review
by Andrzej Krzemienski 23 Apr '26

23 Apr '26

Hi Everyone, This is a short review of Boost.Hub. First, I wanted to yet again thank Joaquín for this contribution. Also, thanks to Ion for managing the review. I personally never had a need for a container with colony/hive/hub properties, so I do not speak as an expert in the problem domain. I have read the docs for the library, investigated the API, compared against std::hive, and played with the library on Compiler Explorer (GCC 15.2) trying to break it. I recommend accepting Hub into Boost. For me, it is equally fine whether this would be a separate library or part of Boost.Container. The library is clearly useful. It belongs in Boost more than in the Standard Library. Regarding the design, there is not much flexibility here: it has already been designed while standardizing std::hive. Although the STD has this impractical type requirements Container and SequenceContainer that (i) are not useful and (ii) do not play well with std::hive, so Boost.Hub has a chance to set things straight. For instance, neither hub nor hive are SequenceContainers, as pointed out in another thread. As indicated in another thread, I recommend making the `visit` functions free functions and renaming them to `for_each` and `for_each_while` (as per Joaquí's suggestion). While the latter name is funny, it is the most adequate one also. This could also be a customization point for all containers: it would default to regular `std::for_each` but offer container authors to provide a faster implementation. We are encouraged to prefer Boost's Hub over Hive based on numbers, but it is not clear to me if the better numbers are due to the necessary API changes, or because Joaquín is a better implementer. What was the primary motivation to scrap the block size control? Regarding the documentation, I find the one currently present in the README satisfactory (modulo the SequenceContainer requirements), and friendlier than these in Boost.Container. So I wonder what the effect of merging would be. Regarding the implementation, I didn't have time to follow all of it but: 1. It is impressive that it is only 1800 lines. 2. It is easy to read and understand; also well documented, where needed. 3. I am concerned about the usage of BOOST_LIKELY. Are these the source of performance? It is my understanding that they are very fragile and may give opposite effects once something changes in the compiler implementation. Plus it is easy to fabricate the data that will make the program go slow when the "negative" branches are deliberately triggered. 4. There is this line: `size_type memory() const noexcept // TODO: remove` Is this something to be fixed? 5. Compiling with -Wall gives me a warning in GCC when sorting an empty hub: a zero-sized heap array is allocated: https://godbolt.org/z/dWvxv9n8s This is technically fine to allocate such arrays, but maybe it is worth to make -Wall clean. I know that Joaquín is responsive and am confident that the Hub implementation will be maintained. Regards, &rzej;

4 5

[Release] The master branch is now open
by Marshall Clow 23 Apr '26

23 Apr '26

Thank to everyone for their patience. The next release cycle will begin in late June https://www.boost.org/calendar/ — The release managers

1 0

[hub] Porting and pre-review experiments
by Ion Gaztañaga 22 Apr '26

22 Apr '26

Hi, Since the review was announced, I've doing some experiments with te proposed data structure. I've collected some notes for technical discussion. Porting and benchmarking -------------------------- I took the hub proposal and did a porting (the initial version was AI-assisted, a very good starting point) that I tuned until the result was good enough for a prototype. It's called "nest" (I could not find a fancy name starting with "h", sorry) here: https://github.com/boostorg/container/blob/develop/include/boost/container/… with a bench (based on the one provided by hub) here: https://github.com/boostorg/container/blob/develop/experimental/bench_hub.c… The porting supports all the range of compilers Boost.Container is tested and uses internal Boost.Container utilities. So the first conclusion is that "hub" is perfctly integrable into Boost.Container at the same level as other existing containers with a low effort. Porting performance ------------------- In my local benchmarks the ported container achieves similar performance results, although there are some outliers with some tools (e.g. clang) that I haven't investigated enough. Also, I only tested this on x86/x64, Windows/Linux in my desktop machine, so probably there are rough edges here and there. Benchmarking is certainly magic, I tried to use recommended "clobber()"-like instructions before benchmarked operations, but probably many boost authors would measure this much better than me. Data structure configuration options ----------------------------------- I also added to "nest" configurability options in order to test other performance decisions Joaquín has made: - *prefetch< boolean >* --> Activates prefetching for the nest container to see if prefetching improves benchmark results - *stored_data_in_block< boolean >* --> hub stores 64 values of data independently from the "block" (metadata with the mask and the linked list pointers). When "true", it stores values in the same struct as the metadata (so it allocates metadata + data in the same block) //An example of a modified configuration nest < element //element type , void //default allocator , nest_options_t< prefetch<false>, store_data_in_block<true> > >; Supporting these options is not complicated, so they could probably be added to "hub" if it's accepted and we can measure some difference on some platforms. ---------------------------------------- Prefetch/stored_data_in_block performance difference ---------------------------------------- Using the above options, it's difficult to see if prefetching or storing data on the block noticeably improves performance in my computer. I see contradictory results depending on the OS (Linux/Windows) or compiler (MSVC/Clang-CL, GCC) I theory I would expect storing data and metadata in the same allocation would help a bit, but I could not have a clear answer. I imagine that results could differ on a deeply embedded machine versus a desktop/server CPU. My conclusion is that the defaults chosen by Joaquín are correct, at least for usual Server/Desktop machines. -------------- Prefetch changes ----------------- I experimented with some prefetch changes in iterator's operator++ https://github.com/boostorg/container/blob/develop/include/boost/container/… and operator--: https://github.com/boostorg/container/blob/develop/include/boost/container/… Basically prefetching the first slot with a value in the array for operator++ or the last one in operator-- instead of always prefetching the start of the array. I only see a slight improvement (or maybe it's a place effect). -------------- Local/segmented iterators -------------- I tried to implement efficient segment https://github.com/boostorg/container/blob/develop/include/boost/container/… and local_iterators https://github.com/boostorg/container/blob/develop/include/boost/container/… in order to test if hub can take advantage of generic segmented algorithms. The problem I found with my implementation is that the local iterator is nearly as expensive as the general iterator, because it must navigate through the data array using nearly the same bit-tricks. I managed to make the difference between local_iterators (operator-) constant-time (basically counting the number of 1s in the mask between both positions) and that could have a slight advantage if the algorithm does some size-bounded computation (say, algorithms like count_n, fill_n, ...): https://github.com/boostorg/container/blob/develop/include/boost/container/… In my implementation it's also more efficient to only support positive differences (in the implementation the general implementation supporting negative differences is present but disabled), which is the usual case for iterator ranges in algorithms. Some algorithms I tested could improve a bit with difference operation, but the segmented approach was still more inneficient than using general iterators. Probably Joaquín can improve it and make it sufficiently performant. Hub's iterators are bidirectional but it's possible to make the local_iterator random-access (the needed operations can be made O(1)). However, the performance of my implementation was not good enough IMHO, so probably not very practical. You have the prototype here: https://github.com/boostorg/container/blob/develop/include/boost/container/… -------------- Summary -------------- - hub's defaults seem correct and performant - I found hub is faster than the plf_hive, as Joaquín claimed. - It's possible to fully integrate hub at the same level as other containers, with moderate effort. A prototype (nest) is already there with similar performance. - I enjoyed reviewing the implementation, more details about my design review in the official review I plan to make. Best, Ion

2 2