- Boost - lists.boost.org

[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

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

22 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

3 5

[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

Fwd: Build failed: safe_numerics 1.0.152-master
by Robert Ramey 22 Apr '26

22 Apr '26

I get these messages from time to time. It seems to indicate that it's related to a commit made in 2021. What's up with that? Also if I make a change that touches only the documentation, it seems it runs the CI on the whole library. It's not a problem, as I just ignore them, but it seems to be a waste of resources. Robert Ramey -------- Forwarded Message -------- Subject: Build failed: safe_numerics 1.0.152-master Date: Wed, 22 Apr 2026 14:58:39 +0000 From: AppVeyor <no-reply(a)appveyor.com> To: ramey(a)rrsd.com Build safe_numerics 1.0.152-master failed Commit 777e0be5ec by Peter Dimov on 10/28/2021 7:44 PM: Add a Boost-friendly subproject case to CMakeLists Configure your notification preferences

2 1

[hub] Hub is not a SequenceContainer
by Andrzej Krzemienski 21 Apr '26

21 Apr '26

std::hive is explicitly stated as not meeting even Container requirements, not to mention SequenceContainer requirements: https://eel.is/c++draft/hive.overview#6 Its location in clause 23.3 "Sequence containers" makes the situation unnecessarily confusing. Container requirements require equality comparison, which std::hive, and therefore boost::container::hub, does not provide. It is debatable whether a container should provide it. It is debatable whether std::unordered_map should provide a quadratic comparison operator only to satisfy the concept. But it is what it is. But this is the least of the concerns. std::hive, and therefore boost::container::hub cannot be a SequenceContainer,because the whole idea of the concept is that the user controls the order of elements manually via insertions at desired places. This is reflected in operation a.insert(p, t) Effects: Inserts a copy of `t` before `p`. (https://eel.is/c++draft/sequence.reqmts#26) std::hive provides an operation with this syntax, but with different semantics: the value of the iterator will be ignored and the container will insert the element at an arbitrary location. Users cannot control the sequence of elements. std::hive is more like std::multiset in this aspect (modulo the performance benefits). But the specification of std::hive, although misleading, in the end states clearly that it is not a sequence container. The docs for boost::container::hub should make it abundantly clear that it does not satisfy the requirements of a SequenceContainer. Regards, &rzej;

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