- Boost - lists.boost.org

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

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

[release] Master branch is now open for bug fixes
by Marshall Clow 14 Apr '26

14 Apr '26

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On April 1st, the master branch closes for all changes. As always, the calendar is at https://www.boost.org/calendar — The release managers

8 19