- Boost - lists.boost.org

Last week in github.com/boostorg (19-25 October 2026)
by Boost Fiscal Sponsorship Committee 26 Oct '26

26 Oct '26

Hi all, Activity on the develop branches of the Boost libraries between 19 and 25 October. This report has been generated automatically with AI. THE NUMBERS - 260 commits on develop (21 CI-related) - 46 pull requests opened against develop, 57 merged - 14 issues opened, 28 closed - 35 libraries with activity, 30 contributors Most active libraries: - Asio: 72 commits PRs: 0 opened, 0 merged; issues: 0 opened, 0 closed - Graph: 17 commits PRs: 16 opened, 15 merged; issues: 1 opened, 0 closed - Container: 37 commits PRs: 0 opened, 0 merged; issues: 0 opened, 1 closed - Fiber: 18 commits PRs: 0 opened, 7 merged; issues: 0 opened, 1 closed - IOStreams: 16 commits PRs: 1 opened, 0 merged; issues: 0 opened, 4 closed - Interval: 7 commits PRs: 4 opened, 4 merged; issues: 2 opened, 3 closed - Intrusive: 20 commits PRs: 0 opened, 0 merged; issues: 0 opened, 0 closed - Decimal: 5 commits PRs: 2 opened, 5 merged; issues: 2 opened, 5 closed Most active contributors: - Christopher Kohlhoff (72 commits, 1 library) - Ion Gaztañaga (64 commits, 4 libraries) - Mateusz Jakub Fila (17 commits, 1 library) - Tobias Stensbeck (16 commits, 1 library) - Peter Dimov (14 commits, 2 libraries) - Jean-Louis Leroy (10 commits, 1 library) - Arnaud Becheler (9 commits, 2 libraries) - Andrea Cassioli (7 commits, 1 library) HIGHLIGHTS Asio Christopher Kohlhoff pushed 72 commits on 21 October. New features include asio::eager, a completion token that starts an operation at once and returns a handle to await later; asio::trampoline, an executor adapter that batches nested submissions; a dependency-free spawn() for x86-64 and AArch64 on Linux and macOS (Boost.Context stays the default); a "spin" reactor backend that avoids epoll_wait-style syscalls; and Perfetto-format handler tracking. channel and concurrent_channel move to the asio namespace, and ready() is deprecated in favour of can_receive(). Fixes cover a possible deadlock in the reactor, a hang in cancel_after/cancel_at with reentrant cancellation and duplicate work counting. poll() now runs the scheduler's task at most once per call. The rest is mostly performance work. Intrusive, Container and Move Ion Gaztañaga reviewed exception guarantees across the three libraries. In Intrusive, move assignment now copies the predicates and moves the nodes instead of swapping, a potentially breaking change; BOOST_INTRUSIVE_MOVE_ASSIGNMENT_SWAPS restores the old behaviour. Every Intrusive container got a friend swap, and swaps and move constructors got conditional noexcept. Container got many noexcept corrections and allocator fixes: private_adaptive_pool::allocate not throwing bad_alloc, a division by zero in alignment-only adaptive pools, an overflow in the aligned_allocate fallback, a string bug when moving to the internal buffer, and devector reallocating despite enough capacity. Move fixed is_constructible on GCC 8-11 in C++03 mode. Graph Arnaud Becheler fixed binary serialization of adjacency_list, whose layout changed by accident in 1.92: archives written by 1.92 can't be read by other releases, and 1.93 goes back to the 1.91 layout. He also extended stateful visitors to planar face traversal, make_maximal_planar, make_connected and make_biconnected_planar, and moved the distributed parts of BGL into GraphParallel. Andrea Cassioli, Varun Sharma and Sayan Samanta removed more legacy compatibility code. New PRs: #664, deprecating labeled and named graphs; #656, Kerem Okyay's fix for #655, a colour map from boykov_kolmogorov_max_flow that is not a minimum cut. Charconv Michiel van Slobbe fixed five writes past the end of a buffer in to_chars (#314 to #318). Several paths wrote a minus sign or a zero without checking the room left: into an empty range, for negative 128-bit integers and for negative zero. Some of them then reported success. General format with a large precision overflowed a stack buffer by one byte for some negative values. Decimal Shen-Ta Hsieh fixed a series of defects he had reported: fmod, remainder and remquo are now exact for exponents far apart (#1517), scalbn and scalbln handle large exponents, acosh and atanh give NaN outside their domain, fma no longer drops a small addend in a tie, and fdim is right for infinities and signaling NaNs. New PRs: #1529, for #1528, equal infinities with payload bits hashing differently. Interval Square roots of point intervals could miss the true root. Sonny Guardian stopped GCC with -frounding-math from reusing the downward-rounded root for the upper end (#61, fixes #60). Sayan Samanta made 32-bit MSVC use x87 fsqrt or SSE, because its runtime sqrt ignores the rounding mode (#64), and Andrey Semashev optimised the SSE2 path. Sayan Samanta also kept GCC from moving x87 arithmetic across the rounding-mode change (#62, fixes #41). Math Nick Thompson added two global optimisers, multilevel coordinate search (closes #1577) and TuRBO, a trust-region Bayesian method, and removed Eigen from CMA-ES. Jacob Hass merged Gauss-Laguerre and Gauss-Jacobi quadrature with anti-Gauss error estimates (#1517, 33 comments). New issues: #1585, documentation for the new quadratures; #1586, hermite, jacobi and laguerre zeros as special functions. JSON Dmitry Arkhipov merged a refactor of how users customise conversion categories (#1156) and ranked described classes lowest ahead of reflection (#1205). New PRs: #1211, splitting a parse_into test that needed over 3GB to build; #1213, for #1212, an option to stop relying on the no_destroy attribute. New issues: #1212, a linker error with Clang on Windows against an MSVC-built Boost (6 comments); #1214, documenting the config macros. Fiber Mateusz Jakub Fila merged CUDA and HIP work from August and September: the HIP integration now uses its own namespace, callbacks use LaunchHostFunc where available, and cudaLaunchHostFunc_v2 flags can be passed (#350). Helena Pankov's futex support for macOS 14.4 and later (#330), first written in April 2025, was merged too. Also last week * UUID and System: Peter Dimov added std::format support to UUID (fixes #201) and made System's to_string_formatter conform to std::formattable. * Beast: Mohammad Nejati's permessage-deflate offer no longer sends server_max_window_bits=15, which some servers reject (fixes #2671), and sends client_max_window_bits without a value. * MSM: Christian Granzin removed the experimental status of backmp11, now the recommended back-end, and removed its active state switch policies and deprecated process_result values. * OpenMethod: Jean-Louis Leroy fixed or annotated the open Coverity defects and merged named_static_rtti for class identity across shared libraries (#127). New issues: #137, static validation of closed overrider sets. * IOStreams: Tobias Stensbeck made the C++11 and CMake 3.8 requirements explicit and fixed test warnings. New PRs: #195, a buffer overrun in range_adapter, from @aouxwoux. * Lockfree: Michiel van Slobbe stopped Clang turning spsc_queue's index wrap into a division on every push and pop (#144). * Config and Predef: Matt Turner added Alpha to the architecture checks. * Wave: Martin Medler added a C++14 language mode. New PRs: #276, a C++26 mode. * New issues and PRs: Process PR #571 (OpenBSD descriptor cleanup), Redis PR #441 (moved-from flat_tree), ProgramOptions PR #161 (C++20 module), GIL issue #817 (Iterator and MPL dependencies). CI MAINTENANCE * Boost.CI: Alexander Grund added Coveralls as a coverage option, made the OpenCppCoverage install more reliable and fixed the Xcode SDK setup; Jean-Louis Leroy fixed Homebrew Clang on macos-26 (#353). * IOStreams: Tobias Stensbeck overhauled the workflow: containers for old compilers, retired runners dropped, GCC 15/16, Clang 20-22, MSVC 14.5 and macOS 26 added, Travis and AppVeyor removed. * Container, Intrusive, Move and Interprocess: Ion Gaztañaga added CMake-based test runs to GitHub Actions. * Interval: Sayan Samanta fixed link failures with Homebrew Clang on macos-26. * UUID: Peter Dimov added libc++ testing. Have a good week!

6 12

Introducing compile_assert C++ Proposal P4021
by Jonathan Grant 25 Oct '26

25 Oct '26

Hello I'd like to introduce my P4021 - compile_assert, compile-time diagnostics for expressions that can be proven at compile time. ie they are not const, constexpr, consteval. https://isocpp.org/files/papers/P4021R2.pdf There's a github repo with a testsuite, showing lots of simple examples. It's a useful tool to detect issues at compile time, like nullptr dereferences, divide by zero, array subscript errors. It diagnoses invariants that are proven false, as well as invariants that are not-proven. Helps make software more robust. Handy for Functional Safety. It does this by identifying code that is reachable, but should not be. Could something like this be added to Boost? I also hope tools like Claude could utilise compile_assert() to evaluate open source software. Regards Jonathan

1 0

Boost 1.93.0 closed for new libraries and breaking changes
by Marshall Clow 22 Oct '26

22 Oct '26

Current status: Release branch is closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries without release manager review. Next milestone: Boost 1.93.0 will close for major changes on Wednesday, October 28 Calendar is here: https://www.boost.org/calendar/ — The Release Managers

1 0

Unmaintained libraries: a tentative list
by Joaquin M López Muñoz 22 Oct '26

22 Oct '26

It is generally known within the community that some of the libraries in Boost are not being properly maintained: issues pile up without a prompt (or any) response from the nominal maintainers, eroding the libraries' usefulness and, ultimately, their viability. There are a number of stalwart contributors (Peter Dimov, Andrey Semashev, and others) who work to make sure CI tests stay green throughout the project, but beyond that they can't possibly address outstanding issues and evolution requests for all libraries. Any initiative to try to remedy this situation begins with identifying its true extent. My colleagues at the FSC and I have gone through all Boost libraries and identified those that we regard as unmaintained, as evidenced by the presence of many important issues that go unresolved without anyone addressing them. This is the list: accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap Any such assessment is a little fuzzy by definition, so the cutoff point for what's considered maintained or not is subject to discussion. I'd like to request your feedback: * If you think some entry in this list should be removed (because you're the maintainer or you know the library is actually maintained and we got it wrong), please say so. * Conversely, tell us if you feel some Boost library not in the list should be included. * Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries. For starters, unmaintained libraries could be labeled as such on the website to attract people potentially interested in taking over (and to warn potential users about long-term adoption risks). Thank you! Best, Joaquín M López Muñoz Fiscal Sponsorship Committee

16 26

Re: Unmaintained libraries: a tentative list (Jason Rice)
by Jason Rice 21 Oct '26

21 Oct '26

Regarding Boost.Hana, I was given Collaborator status by the original author which I think he implied it as an honorary role. I would be willing to maintain it if he gave explicit permission to do so. I would be especially interested, if it meant allowing to move to C++26 when reflection arrives. Its interface involves functional programming concepts rooted in category theory which make it interesting and relevant, but compile times can be untenably slow for non-trivial use. On a more general note, perhaps libraries that would be otherwise removed could be allowed to be updated possibly with breaking changes to require newer versions of the standard so they have value and continued interest from collaborators or potential collaborators. Jason Rice > _______________________________________________ > Boost mailing list -- boost(a)lists.boost.org > To unsubscribe send an email to boost-leave(a)lists.boost.org > https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ >

2 1

Re: Unmaintained libraries: a tentative list
by Andrea Cassioli 21 Oct '26

21 Oct '26

IMHO the safest path is to make sure the status of a library is clearly flagged * on the Boost web site * on the github repo (readme and contribution guide?) More over a cleat path for potential new maintainers should be clear. Users, including other boost libraries, then can decide whether to take a risk of using a library with basically no support (personally I would not). On Wed, 21 Oct 2026 at 02:00, <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > Today's Topics: > > 1. Re: Unmaintained libraries: a tentative list (Jason Rice) > (Jason Rice) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 20 Oct 2026 15:35:17 -0700 > From: Jason Rice <ricejasonf(a)gmail.com> > Subject: [boost] Re: Unmaintained libraries: a tentative list (Jason > Rice) > To: boost(a)lists.boost.org > Message-ID: > < > CANfsYuxjMqPvia5Sk3DiT2h8jJkgxWAThDQo2yQsioHpdKDqug(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Regarding Boost.Hana, I was given Collaborator status by the original > author which I think he implied it as an honorary role. I would be willing > to maintain it if he gave explicit permission to do so. > > I would be especially interested, if it meant allowing to move to C++26 > when reflection arrives. Its interface involves functional programming > concepts rooted in category theory which make it interesting and relevant, > but compile times can be untenably slow for non-trivial use. > > On a more general note, perhaps libraries that would be otherwise removed > could be allowed to be updated possibly with breaking changes to require > newer versions of the standard so they have value and continued interest > from collaborators or potential collaborators. > > Jason Rice > > > > _______________________________________________ > > Boost mailing list -- boost(a)lists.boost.org > > To unsubscribe send an email to boost-leave(a)lists.boost.org > > https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Boost mailing list -- boost(a)lists.boost.org > To unsubscribe send an email to boost-leave(a)lists.boost.org > https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ > > > ------------------------------ > > End of Boost Digest, Vol 7876, Issue 4 > ************************************** >

1 0

[release] Starting the 1.93.0 release cycle
by Marshall Clow 19 Oct '26

19 Oct '26

This Wednesday (21-October): Release branch is closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries without release manager review. Calendar is here: https://www.boost.org/calendar/ — The release managers

1 0

[iostreams] Maintenance status
by Tobias Stensbeck 19 Oct '26

19 Oct '26

Hello Boost developers, I recently opened a PR on iostreams (#194) and noticed afterwards that the project is quite inactive (only 2 commits in the last year and issues/PRs sit unanswered for years). I would like to understand whether anyone is currently maintaining iostreams and reviewing contributions. This led me to search the mailing list a bit: The original author, Jonathan Turkanis, is still listed as the current maintainer, but even as far back as 2010 there was a message from Edward Diener saying that iostreams looks abandoned [1]. In 2018 Diener wrote [2]: "I have sort of taken over maintenance, since the original developer stopped paying attention to the library a long time ago. However I do not mind if it gets added to CMT and others can help maintaining the library." He was active in the repository from 2016-2021. From 2021 until now the most active contributor has been Peter Dimov (mostly CI/build maintenance). So my questions are: 1. Is there currently an active maintainer for iostreams? 2. Is the Community Maintenance Team still active, and if so, who are its members and could iostreams be put under its care? 3. If no maintainer is currently available, what is the process for arranging ongoing maintenance? Best regards, Tobias Stensbeck Graphics Engineer, Threedy GmbH [1] https://lists.boost.org/archives/list/boost@lists.boost.org/message/YDAE7PN… [2] https://lists.boost.org/archives/list/boost@lists.boost.org/message/LQPXQW7…

3 4

Failed to build boost.locale with iconv - cross compiling on linux targetting Mac OSX arm64
by Frédéric 18 Oct '26

18 Oct '26

Hi, I'm trying to build boost 1.92 on linux targetting arm64-apple-darwin21.4 but it fails on boost.locale because it cannot compile has_external_iconv. iconv is correctly build with libraries for the right architecture. I'm able to run the iconv binary on a mac without any issue. I found why has_external_iconv fails to build but do not know what to do to change the automatic settings to make it works. To compile has_external_iconv and confirm that I have the library in the path I provided, boost.build adds the following flags that make the compilation fail: -m64 --target=arm64-apple-darwin What makes it work is to remove -m64 and have --target=arm64-apple-darwin21.4 How can I have that? Here is my user-config.jam: using clang-darwin : : arm64-apple-darwin21.4-clang++ : <archiver>arm64-apple-darwin21.4-ar <ranlib>arm64-apple-darwin21.4-ranlib <cxxflags >"-I/softs/arm64-clang-22.1.8/release/iconv/include" <cxxflags>"-I/softs/arm64-clang-22.1.8/release/gettext/include" <cxxflags>"-I/softs/ar m64-clang-22.1.8/release/bzip2/include" <cxxflags>"-I/softs/arm64-clang-22.1.8/release/zlib/include" <cxxflags>"-I/softs/arm64-clang-22.1.8 /release/jpeg-turbo/include" <cxxflags>"-I/softs/arm64-clang-22.1.8/release/xz/include" <cxxflags>"-I/softs/arm64-clang-22.1.8/release/tiff /include" <cxxflags>"-I/softs/arm64-clang-22.1.8/release/png/include" <cxxflags>"--target=arm64-apple-darwin21.4" <cxxflags>"-std=c++14" <c xxflags>"-mmacosx-version-min=12.3" <cxxflags>"-O2" <cxxflags>"-DNDEBUG" <linkflags>"-mmacosx-version-min=12.3" <linkflags>"-L/softs/arm64- clang-22.1.8/release/iconv/lib" <linkflags>"-L/softs/arm64-clang-22.1.8/release/gettext/lib" <linkflags>"-L/softs/arm64-clang-22.1.8/releas e/bzip2/lib" <linkflags>"-L/softs/arm64-clang-22.1.8/release/zlib/lib" <linkflags>"-L/softs/arm64-clang-22.1.8/release/jpeg-turbo/lib" <lin kflags>"-L/softs/arm64-clang-22.1.8/release/xz/lib" <linkflags>"-L/softs/arm64-clang-22.1.8/release/tiff/lib" <linkflags>"-L/softs/arm64-cl ang-22.1.8/release/png/lib" ; Here is my b2 command: CC="arm64-apple-darwin21.4-clang" CFLAGS="-O2 -DNDEBUG --target=arm64-apple-darwin21.4 -mmacosx-version-min=12.3" CXX="arm64-apple-darwin21 .4-clang++" CXXFLAGS="-O2 -DNDEBUG --target=arm64-apple-darwin21.4 -std=c++14 -mmacosx-version-min=12.3" OBJCXXFLAGS="-O2 -DNDEBUG --target =arm64-apple-darwin21.4 -std=c++14 -mmacosx-version-min=12.3" CPPFLAGS="-I/softs/arm64-clang-22.1.8/release/iconv/include -I/softs/arm64-cl ang-22.1.8/release/gettext/include -I/softs/arm64-clang-22.1.8/release/bzip2/include -I/softs/arm64-clang-22.1.8/release/zlib/include -I/so fts/arm64-clang-22.1.8/release/jpeg-turbo/include -I/softs/arm64-clang-22.1.8/release/xz/include -I/softs/arm64-clang-22.1.8/release/tiff/i nclude -I/softs/arm64-clang-22.1.8/release/png/include" LDFLAGS="-mmacosx-version-min=12.3 -L/softs/arm64-clang-22.1.8/release/iconv/lib -L /softs/arm64-clang-22.1.8/release/gettext/lib -L/softs/arm64-clang-22.1.8/release/bzip2/lib -L/softs/arm64-clang-22.1.8/release/zlib/lib -L /softs/arm64-clang-22.1.8/release/jpeg-turbo/lib -L/softs/arm64-clang-22.1.8/release/xz/lib -L/softs/arm64-clang-22.1.8/release/tiff/lib -L /softs/arm64-clang-22.1.8/release/png/lib" AR="arm64-apple-darwin21.4-ar" AS="arm64-apple-darwin21.4-as" RANLIB="arm64-apple-darwin21.4-ran lib" BUILD_MACHINE="x86_64-unknown-linux-gnu" HOST_MACHINE="arm64-apple-darwin21.4" ./b2 -d2 -j16 boost.locale.iconv=on boost.locale.icu=of f boost.locale.std=off -sICONV_PATH=/softs/arm64-clang-22.1.8/release/iconv -sBZIP2_INCLUDE=/softs/arm64-clang-22.1.8/release/bzip2/include -sBZIP2_LIBPATH=/softs/arm64-clang-22.1.8/release/bzip2/lib -sZLIB_INCLUDE=/softs/arm64-clang-22.1.8/release/zlib/include -sZLIB_LIBPATH=/ softs/arm64-clang-22.1.8/release/zlib/lib --layout=system --user-config=user-config.jam --without-mpi --without-python --without-context -- without-coroutine link=static threading=multi runtime-link=shared target-os=darwin architecture=arm binary-format=mach-o threadapi=pthread define=BOOST_FILESYSTEM_NO_DEPRECATED define=BOOST_LOG_WITHOUT_EVENT_LOG variant=release install Thanks for help, F

3 5

[graph] Boost.Graph 1.95 will be C++17
by Arnaud Becheler 30 Sep '26

30 Sep '26

Dear Boost.Graph community, Jeremy Murphy and I are happy to announce that in two release cycles (Boost release 1.95 in summer 2027) Boost.Graph will be bumped to C++17. This decision follows two polls that did not surface any C++14 user base or demand: Github Poll: https://github.com/boostorg/graph/discussions/490 Reddit Poll: https://www.reddit.com/r/cpp/comments/1tc1v6x/whats_the_highest_c_standard_… This standard version bump will bring benefits for maintenance, API and dependencies reduction. We will not be able to guarantee backward compatibility with C++14. Please contact us if you are stuck in C++14. The GIthub Discussion lives here: https://github.com/boostorg/graph/discussions/613 Have a wonderful fall season, Best Regards, Arnaud Becheler

3 5