April 2026 - Boost - lists.boost.org

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

21 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

8 14

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

20 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

1 0

Boost 1.9 on Mint 20.1
by Martin McGlensey 20 Apr '26

20 Apr '26

I install Boost 1.9 on my Mint 20.1 system. I folowed al the steps shown on the Boost web page. It appeared to install without errors. I also enter the three environment varibles per the instructions. Now when I try to install a program that needs Boost >1.83 it defaults to Boost 1.7. Why does the program (wsjt-x Ver 3.0) not see Boost 1.9? What can I do to make Boost 1.9 avalable to fill this dependecy? Thanks Marty McGlensey843-546-4822mmcglensey(a)yahoo.com

2 1

[exception] Proposal: noexcept intrusive successor needed
by Udo Steinbach 20 Apr '26

20 Apr '26

Hello boost people, I am not using boost::exception. I have my own solution, a beginner-style base class with a unique_ptr to itself and derivations for every information, since 10 years before boost::exception came out. I am thinking about to rebuild it as a mix of boost::exception's heterogeneous container and my class' reliability in any situation. Now I have the idea, that someone other may interested to publish something like that as part of boost, even the boost::exception authors? I'd love to contribute, but my working style and libraries do not fit boost conventions, so I would end up maintaining two identical libraries. But I'd be happy to help if someone takes it forward. Thesis 1: During error handling, no errors may occur. An error object must not be overwritten by a secondary failure due to random allocation success. Therefore noexcept for almost all functions is mandatory. Without it, you either lose the original error (masked) or std::terminate() the program. It is better to drop info-objects instead. My classes have passed all such tests --- they only fail when the program is already uncontrollable (e.g., no memory left even for a throw itself). Anyway, my class proves that runtime error handling and presenting can be rock-solid stable with pure C++. Thesis 2: Therefore we need minimalistic structures, exception free memory (new (std::nothrow)) and functions to copy objects without exceptions, static_assert(std::is_nothrow_..._v) and other little neat things. Whatever can throw there must be a catched, nothing escapes boost::exception2 (except few output functions). Thesis 3: std::expected, boost::leaf & Co. pursue a different goal than error handling. A error is a rare event during program lifetime. We account for it, but don't expect it. In contrast, error-as-return-value is an expected value handled locally. And: not every technical issue is a error from user's perspective, e.g. file-not-found. Only in rare cases one may return something like result<T,boost::exception>, e.g. the caller needs the data or message without catching an exception. Classes like boost::exception or mine are the only C++-idiomatic way to handle errors. Thesis 4: std::exception is less then useless. It does not transport enough information to generate useful text. Instead throwing them hinders error handling, I have to catch and convert them everywhere. A small contraindication: An empty boost::exception has no distinguishable text. If my thrown TFileError is empty, it has "A file error...". But that's irrelevant, one need external help to produce a no memory condition at throw. I see errors with user's eyes, it's about generating reliable diagnostic text. But this doesn't affect the structures or query capabilities. What do you think? Looking forward to your thoughts! says Udo sitting in rainy Oldenburg, Germany -- Mit Radwegen lernte ich den Menschen kennen. http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E

1 0

[release] Boost 1.91 RC1 available
by Marshall Clow 19 Apr '26

19 Apr '26

The first release candidates for the 1.91.0 release are now available at: <https://archives.boost.io/release/1.91.0/source/> The SHA256 checksums are as follows: 9446c37fd86fecd95254ebe5d368a66ef9b09cec4592b2746979076657e24e65 boost_1_91_0_rc1.7z 5734305f40a76c30f951c9abd409a45a2a19fb546efe4162119250bbe4d3a463 boost_1_91_0_rc1.tar.gz 69c6f32fbda3c478fb310ec251e6699e5e584dbc71afb5425c2f6e98c9540a77 boost_1_91_0_rc1.zip de5e6b0e4913395c6bdfa90537febd9028ea4c0735d2cdb0cd9b45d5f51264f5 boost_1_91_0_rc1.tar.bz2 As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

6 8

[hub] on the specialized iteration over elements
by Andrzej Krzemienski 17 Apr '26

17 Apr '26

Hi Everyone, Once again, thank you Joaquín for this contribution to the community. This is not really a review, but I wanted to talk about this idea to implement a specialized algorithm for iterating over the container elements in the form of hub::visit. First, should we draw from this a more general observation that iterators are an abstraction with overhead, and other containers (deque?) would also benefit from this inversion-of-control approach? Second, I think that the most natural naming choice for this operation is "for each", not "visit". It does practically the same thing as `std::for_each`. Third, the interface is rather unusual, and it allows one hub to iterate over another hub's elements: hub<T> h, g; h.visit(g.begin(), g.end(), fun); https://godbolt.org/z/bbb765bb1 It looks like this function should be a free function rather than a member function. And if there is a reason to make it a member function, at minimum add a precondition that both the iterators should point inside the container. Regards, &rzej;

6 16

Warnings with boost 1.91.0 and clang-21
by Marshall Clow 16 Apr '26

16 Apr '26

Here’s the warnings counts (by standards level) from Boost. 1.90.0: (Apple clang 17): logs/clang11-build.txt: 34 logs/clang14-build.txt: 40 logs/clang17-build.txt: 40 logs/clang20-build.txt: 44 logs/clang23-build.txt: 48 logs/clang2c-build.txt: 48 Here are the same numbers from Boost 1.91.0 (Apple clang 21) logs/clang11-build.txt: 79 logs/clang14-build.txt: 91 logs/clang17-build.txt :91 logs/clang20-build.txt: 99 logs/clang23-build.txt: 103 logs/clang2c-build.txt: 3167 Most of the bugs fall into three bins: https://github.com/boostorg/proto/issues/37 https://github.com/bfgroup/b2/issues/566 And several libraries (at least regex and spirit) instantiate std::char_traits types that are not ‘characters’ Example: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__fwd/string.h:45:41: warning: 'char_traits<unsigned char>' is deprecated: char_traits<T> for T not equal to char, wchar_t, char8_t, char16_t or char32_t is non-standard and is provided for a temporary period. It will be removed in a future release, so please migrate off of it. [-Wdeprecated-declarations] 45 | template <class _CharT, class _Traits = char_traits<_CharT>, class _Allocator = allocator<_CharT> > | ^ ./boost/xpressive/traits/cpp_regex_traits.hpp:321:18: note: in instantiation of default argument for 'basic_string<char_type>' required here 321 | typedef std::basic_string<char_type> string_type; | ^~~~~~~~~~~~~~~~~~~~~~~ ./boost/xpressive/traits/cpp_regex_traits.hpp:673:22: note: in instantiation of template class 'boost::xpressive::cpp_regex_traits<unsigned char>' requested here 673 | inline unsigned char cpp_regex_traits<unsigned char>::hash(unsigned char ch) | ^ And /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__fwd/string.h:45:41: warning: 'char_traits<unsigned int>' is deprecated: char_traits<T> for T not equal to char, wchar_t, char8_t, char16_t or char32_t is non-standard and is provided for a temporary period. It will be removed in a future release, so please migrate off of it. [-Wdeprecated-declarations] 45 | template <class _CharT, class _Traits = char_traits<_CharT>, class _Allocator = allocator<_CharT> > | ^ ./boost/spirit/home/support/utf8.hpp:24:18: note: in instantiation of default argument for 'basic_string<ucs4_char>' required here 24 | typedef std::basic_string<ucs4_char> ucs4_string; | ^~~~~~~~~~~~~~~~~~~~~~~ — Marshall

1 0

Support status for C++03 (std=c++03) in Boost [Version] on RHEL 9
by Piyush Anand 16 Apr '26

16 Apr '26

Hello Boost Community, I am currently planning a large-scale migration of a legacy codebase from SourcePro Rogue Wave to Boost. Due to strict production requirements, we must maintain the -std=c++03 flag across environments: RedHat 9 (GCC 5.x) My Question: Is there any version of Boost, which can be considered the "Long Term Support" equivalent for C++03, for which Boost also release latest patch or security vulnerabilities or actively maintain that version? From older post/blogs, it seems Boost does not manage c++03 standard and provide support of latest standard of c++ only i.e. C++14 and so on. Thanks And Regards, Piyush

5 6

[release] Master branch is now closed for the release
by Marshall Clow 16 Apr '26

16 Apr '26

Master is closed for all changes. See the release schedule at http://www.boost.org/calendar — The release managers

1 0

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

15 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

4 4