August 2026 - Boost - lists.boost.org

[container] Boost.Container is header-only again in develop (and hopefully, in 1.93)
by Ion Gaztañaga 01 Sep '26

01 Sep '26

Hi all, Boost.Container has needed separate compilation for about a decade due to two small utilities. The extended allocators (the dlmalloc-derived heap) needed it since late 2013, and the polymorphic memory resources (PMR) since they were added in 2015. On the develop branch for 1.93 I've found a way to make it header-only again, because I think it greatly improves the usability of the library. Since this might cause some problems to users, I'd like to explain a bit how this was done in case some problems are detected and users need some hints to debug it. The need for a compiled library came from globals that were needed for two reasons: * The dlmalloc heap used by the extended allocators. This includes its arena, data structures, mutex, and tuning parameters. Memory allocated through one module (DLL) must be freeable through another (across DLLs). * The polymorphic memory resource singletons. This includes the default-resource slot that set_default_resource() writes and get_default_resource() reads and the global new_delete_resource of null_memory_resource. A compiled library provides this automatically (when properly compiled an linked/loaded), but a header-only library has some problems. Every DLL (on Windows) compiles its own copy. boost::container::pmr::vector allocated in the DLL and destroyed would return its memory to the wrong heap. In Boost 1.93, a private new utility (detail/intermodule_globals.hpp) provides a class (dtl::intermodule_globals<T, Options>) that returns a reference to a single object of type T for each T/Options pair. The object is shared by every module in the process. It is constructed on zero-initialized storage by whichever module reaches it first with some configurable options (like a phoenix singleton for those globals that need to be available to the very end of the program, like a heap allocator). The dlmalloc globals and the PMR globals are the only two users inside the library. On ELF and Mach-O the global object is implemented as a static data member of a class template, with default visibility (so that the loader unifies all the instances from each .so and .elf). On windows and Cygwin, since PE/COFF has no equivalent symbol merging, a shared memory segment is created where a incremental (linear) hash map is built to find singletons by name and those singleton objects are also constructed in that shared memory segmented (accesible by all the DLLs that need access to globals). Boost.Interprocess has a similar utility but it relies on non-trivial Interprocess data structures), it's design is not optimal and I didn't want to make Boost.Container dependant on Boost.Interprocess (that would be a circular dependency). Probably Interprocess will use a similar utility for its module-shared globals in the future if the Boost.Container transition goes reasonably well. Some limitations: * On ELF, STB_GNU_UNIQUE makes the shared object that defines the symbol non-unloadable (e.g. to avoid crashes when calling virtual functions that live on that module). * On windows a similar mechanism (module pinning) is used to avoid unloading the module if the corresponding option is used. * The Windows registry is a fixed-size arena. It is sized (the minimum shared memory is 64KB) for far more singletons than the library uses, so there is some memory waste (in practice, only the virtual address space is reserved, only really used memory is committed). I hope most existing code should continue to work. * BOOST_CONTAINER_DECL still exists and expands to nothing. * BOOST_CONTAINER_DYN_LINK, BOOST_CONTAINER_STATIC_LINK, BOOST_CONTAINER_SOURCE and BOOST_CONTAINER_NO_LIB are still accepted. * BOOST_CONTAINER_HEADER_ONLY has been removed, both as a CMake option and as a macro. I did not add a stub library, not sure how useful is to have it, I think other Boost compiled to header transitions did not add the stub library (Boost.system, on the other hand, provided one for a long time). Some superproject changes will be needed due to this change, Peter Dimov has already identified some changes. If some other Boost libraries or tests are broken due to this header-only transition, let me know so I can help solving them. Thanks, Ion

2 2

The State of Boost at CppCon
by Harold Bott 31 Aug '26

31 Aug '26

Hi all, I'm giving "The State of Boost" at CppCon this year, and before I lock the content down I'd like to hear from the people who actually make Boost what it is. Since this is the first year for a "State of Boost" (I hope this will be a yearly talk!) I wanted to give more than just what happened in the past year. Here's roughly what I plan to cover. First, what Boost is today and why it's worth building on. Second, the people: the founders and the contributors who made Boost possible in the first place. Third, a few specific libraries: Unordered, Intrusive, MultiIndex, and Decimal. Finally, where Boost is heading: the networking work, safety (Profiles), and the Boost Documentary (which will be screened at CppCon). I chose those libraries because I wanted to show a recent one (Decimal) as well as some well established ones (comparing Intrusive and MultiIndex) and show some benchmarks (Unordered). So: does anyone have an issue with the libraries I've picked? Are there libraries you think should be in the talk instead, or alongside them? I'd rather hear it now than after the slides are final. Is anyone attending CppCon? Thanks, Harry

2 2

Re: ABI ms config
by Tom Kent 19 Aug '26

19 Aug '26

(Switching subject, was Re: [release] Boost 1.92 RC1 available) On Mon, Aug 10, 2026 at 7:36 PM Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > On 11 Aug 2026 00:58, Tom Kent via Boost wrote: > > Any ideas where that could be coming from? I'm pretty sure I don't set > that > > manually. > > > https://github.com/boostorg/context/blob/cc1b9e02cd530d6607becc984e1e5bfa4f… > > sysv is set by default. The default_abi rule is used by Boost.Context > project in private requirements, i.e. it applies only to Boost.Context. > If I'm not mistaken, for everyone else the sysv default remains in > effect unless abi is specified on the command line. > > I think, the feature should be made optional with no default. > Boost.Context can continue to use the default_abi rule to deduce it from > the target platform, for everyone else it should not be set. > > > On Sat, Aug 8, 2026 at 12:15 AM <oliver.kowalke(a)gmail.com> wrote: > > > >> for Windows '<abi>sysv' is wrong - I believe it should be '<abi>ms' > >> > >> 08.08.2026 04:16:00 Tom Kent via Boost <boost(a)lists.boost.org>: > >> > >>> Still seeing the same config issue I reported for the beta RC: > >>> > >>> - long double support : yes (cached) [2] > >>> - std_wstreambuf : yes (cached) [2] > >>> error: No best alternative for > >>> /D:/RB/boost_1_92_0/libs/graph_parallel/build/boost_graph_parallel with > >>> <abi>sysv <address-model>32 <architecture>x86 <asynch-exceptions>off > >>> <binary-format>elf <boost.beast.allow-deprecated>on > >>> <boost.beast.separate-compilation>on > >> <boost.cobalt.executor>any_io_executor > >>> <boost.cobalt.pmr>std <context-impl>fcontext <coverage>off > >>> <debug-store>object <debug-symbols>on <embed-manifest-via>linker > >>> <embed-manifest>on <exception-handling>on <extern-c-nothrow>off > >>> <inlining>off <known-warnings>hide <link>shared <midl-robust>yes > >>> <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on > >>> <preserve-test-targets>on <profiling>off <python-debugging>off > >> <python>3.14 > >>> <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native > >>> <strip>off <target-os>windows <testing.execute>on <threadapi>win32 > >>> <threading>multi <toolset-msvc:version>14.1 <toolset>msvc > <variant>debug > >>> <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on > >>> <windows-api>desktop <x-deduced-platform>x86_32 > >>> matched: (empty) > >>> matched: (empty) > >>> - lzma : no (cached) [2] > >>> - zstd : no (cached) [2] > >>> > I've updated my command to include abi=ms but it is still complaining about a similar error: b2 -j%NUMBER_OF_PROCESSORS% --without-mpi --build-dir=D:\RB/bin.v2 --stage-libdir=lib32-msvc-14.1 --build-type=complete toolset=msvc-14.1 address-model=32 architecture=x86 abi=ms stage Performing configuration checks - default address-model : 64-bit (cached) [1] - default architecture : x86 (cached) [1] <snip> - long double support : yes (cached) [2] - std_wstreambuf : yes (cached) [2] error: No best alternative for /D:/RB/boost_1_93_0/libs/graph_parallel/build/boost_graph_parallel with <abi>ms <address-model>32 <architecture>x86 <asynch-exceptions>off <binary-format>elf <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <context-impl>fcontext <coverage>off <debug-store>object <debug-symbols>on <embed-manifest-via>linker <embed-manifest>on <exception-handling>on <extern-c-nothrow>off <inlining>off <known-warnings>hide <link>shared <midl-robust>yes <midl-stubless-proxy>yes <optimization>off <os>NT <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.14 <rtti>on <runtime-debugging>on <runtime-link>shared <stdlib>native <strip>off <target-os>windows <testing.execute>on <threadapi>win32 <threading>multi <toolset-msvc:version>14.1 <toolset>msvc <variant>debug <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <windows-api>desktop <x-deduced-platform>x86_32 matched: (empty) matched: (empty) - lzma : no (cached) [2] - zstd : no (cached) [2] Tom

4 3

Boost Version 1.92.0 Release report
by rob＠cppalliance.org 17 Aug '26

17 Aug '26

Hello Everyone! The Release report for Boost 1.92 is now out and available for all to see! Expect some changes in the next report... https://downloads.cppalliance.org/reports/boost_1_92_0_release_report.pdf Please feel free to leave any feedback if there is additional information you'd like to see!

1 0

Mutli Mini-Review Result
by Matt Borland 17 Aug '26

17 Aug '26

Hello, As the review manager for the Multi mini-review I want to thank everyone that participated in the review. After careful consideration I maintain that Multi is CONDITIONALLY ACCEPTED. The single condition for acceptance is also maintained from the last review, being that the library must pass a documentation review. For transparency the final tally of public and private reviews were Accept: 2, Conditionally Accept: 2, Reject: 1. From the accept reviews we see that there has been improvement in the documentation set, but from the conditional accepts and rejects there is still some more work and polish that is required before merging into Boost. All of the review comments have been turned into tasks lists with a total of ~125 items to address prior to the next review. Lastly, thank you to Alfredo for continuing to work diligently on the library. Best, Matt Boost.Multi Review Manager

1 0

Multi Mini-Review Begins Today
by Matt Borland 13 Aug '26

13 Aug '26

Hello, Today begins the mini-review of Multi, authored by Alfredo Correa. Multi is a modern C++ library that provides manipulation and access of data in multidimensional arrays for both CPU and GPU memory. The review will run through Wednesday 12 August. You can find the library and documentation links below: - https://github.com/correaa/boost-multi - https://correaa.github.io/boost-multi/multi/intro.html The review earlier this year raised a number of issues that primarily revolved around the state of the documentation, not the library itself. I have labeled all of the issues related to conditions found in last review, and many have notes or resolution from Alfredo: https://github.com/correaa/boost-multi/issues?q=is%3Aissue%20state%3Aopen%2… To this end the review will revolve around the current state of the documentation on the branch "boost_review". In your review please explicitly state if you recommend REJECT, ACCEPT, or a conditional acceptance along with the acceptance conditions. Please let me know if you have any questions or concerns. Thank you in advance for your time. Matt Multi Review Manager

5 9

[release] 1.93.0 open for merging
by Ion Gaztañaga 13 Aug '26

13 Aug '26

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: https://www.boost.org/calendar/ Release process: https://www.boost.org/doc/contributor-guide/release-process.html Development practices for developers: https://www.boost.org/doc/contributor-guide/best-practices.html -- The Boost Release Team

1 0

[release] Boost 1.92.0
by Ion Gaztañaga 12 Aug '26

12 Aug '26

Release 1.92.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. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see https://www.boost.org/releases/1.92.0/ You can also download directly from: https://archives.boost.io/release/1.92.0/ To install this release on your system, see https://www.boost.org/doc/user-guide/getting-started.html Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Glen Fernandes and Ion Gaztañaga

4 3

Boost.Capy Review Status: 20 Cartridges Available, Buy Now
by Vinnie Falco 11 Aug '26

11 Aug '26

[image: boost-capy-carts.jpg] -- Vinnie https://wg21.org https://vinniefalco.com

2 2

[release] Boost 1.92 RC1 available
by Ion Gaztañaga 11 Aug '26

11 Aug '26

The first release candidates for the 1.92.0 release are now available at: https://archives.boost.io/release/1.92.0/source/ The SHA256 checksums are as follows: c4a3b310ddd2472416e091067166b0713be97c63f38c212c484ada022fd296ce boost_1_92_0_rc1.tar.gz 57f2ded2390068a44d88748425067e01a8c285257a4d9611d04ade9d8ec68615 boost_1_92_0_rc1.7z c46baee75ed4b558cf6553630d0615a147ed582812917b57e6f0839d1954549f boost_1_92_0_rc1.zip 5c1d40cb8e19adbf740a4ec2da35b3e58f3f5804b1dce44deb53df72193cbc6c boost_1_92_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 9

Re: [multi] Formal Review Begins
by Alfredo Correa 10 Aug '26

10 Aug '26

> Date: Thu, 12 Mar 2026 17:02:50 +0100 > From: Ruben Perez <rubenperez038(a)gmail.com> > Subject: [boost] Re: [multi] Formal Review Begins > To: "Boost developers' mailing list" <boost(a)lists.boost.org> > Message-ID: > <CACR-md+BUG= > 4WSEzNJ5ZYJv6jetTvkhKVGQLmNC0ZzK3AMVK+Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Thu, 5 Mar 2026 at 14:37, Matt Borland via Boost > <boost(a)lists.boost.org> wrote: > > > > Dear All, > > > > The review of Multi by Alfredo Correa begins today, March 5th and goes > through March 15th, 2026. > Hi all, Let me start with a personal apology to Rubén Perez; I completely missed his review from March 12, and it came across as me ignoring it, although it was really constructive in retrospect. I answered most reviews as GitHub issues, but since I didn't see his issue there, it slipped from me. Like the original reviews and his re-review from a few days ago (7 August), I answered in a GitHub issue. So when Ruben said in his August 7 review that "I feel the library is at a similar point as last time I looked at it", he is completely justified, because I accidentally didn't address any of his points. But given the special situation, I feel obligated to give a detailed response to this first review in March. > > This is my review of the proposed Boost.Multi. Thanks Alfredo for > submitting the library and Matt for managing the review. > Thank you, Ruben, for reviewing my library, and apologies again for not addressing your original review from March. (That is why it feels that the library didn't change at all from your point of view). > > - What is your evaluation of the potential usefulness > of the library? Do you already use it in industry? > > I think that it has the potential to be very useful. > I don't use it today, but having it would have been beneficial > for one of my former clients. IMO a library like this should > have a place in Boost. > Thanks > > - What is your evaluation of the design? > > I think the library got its core decisions right. Iterating, > indexing and slicing are elegant. Lazy arrays are great. > > Interaction with std::mdspan could be better. At the moment, > we have a godbolt link with some non-trivial code. mdspan > is already standardized (C++23) and available on some standard libraries. > Functions for easy interoperability should be provided. > C++26 linalg [1] is based on std::mdspan, so providing this will be > important > in the future. > This is answered in the new review in the Github issues (August). Yes, interaction with std::mdspan improved. Arrays and subarrays are implicitly convertible to std::mdspan<T, std::dextents<std::size_t, D>, std::layout_stride> following the current design of the relationship between std::vector and std::span. > As other reviews have mentioned, the reference section is incomplete, > and there are a lot of types and functions in the public boost::multi > namespace that are not documented. This creates a gap on what I can > evaluate > in this review. I don't know if many of these functions (e.g. data(), > data_elements()) > are supposed to be used by the end user or not. > API reference section is now generated automatically with MrDocs; conceptual things that are not well captured by automatic tools have their own section: https://correaa.gitlab.io/boost-multi/multi/reference.html > Aside from this, there are a number of surprising decisions that > have the potential for creating trouble: > > * Indexing uses signed rather than unsigned integers. From a conversation > with the author in Slack, signed-ness was chosen to allow negative > indices (like Python does). The problem is that the actual type is buried > within multiple layers of type aliases. One of these aliases, > multi::size_t, is actually signed, making things even more confusing. > The typedef multi::size_t has been removed to avoid confusion. The index type is a class typedef, e.g. `multi::array<T, D>::index`. > I'd advise to: > * Try to implement the negative indexing feature before anything else. > It doesn't sound like a trivial thing, and should probably be done > before committing to API stability. > Index signedness and negative indexing are separate decisions. The index signedness is a principled decision independent of other features. > * Remove as many type aliases as possible. Use std::ptrdiff_t > everywhere, > which immediately tells the user the type that they're using. > Especially multi::size_t. > Things related to ptrdiff are derived from the allocator type. If I hard-code std::ptrdiff_t, the connection with the allocator will then be lost. In the same way I have array::index (index type), there is array::difference_type. > * Arrays overload the "address of" (operator&). I don't think this is good > practice at all. It's also not mentioned in the docs. > With my system > fmtlib (v9.1), printing subarrays fails to compile because of this. > While it's true that fmtlib should be using std::addressof instead > of raw operator&, > we could avoid the problem altogether. > I think this is a problem with fmt. Although it works for me, at least for basic uses of fmt. (this is addressed in the new GitHub August issue) * Functions like strided() can lead to non-obvious undefined behavior. > I don't think this should be the case. If the performance gain > (after measuring) > is significant, an strided_unsafe() can be added. > Docs mention "The third case is that of iterators of transposed > array." regarding > UB, which I don't really understand. > This is the issue: you allocate 12 elements for a 3x4 array; therefore, there are 13 addressable locations (marked with `o` below). oooo oooo oooo oabc The end() iterator of the first column is ok, it sits in an `o` location. The end() iterator of the second column "sits" in `a` which is not a valid address because it beyond the 12 element allocation (that has only 13 valid addresses). I rewrote the section about UB before the last (August) review. * Initializing and resizing arrays leads to uninitialized elements by > default. > I think this default is confusing, especially because there is a > multi::uninitialized_elements > tag. I'd expect that elements are initialized (safe default) unless > I explicitly use > multi::uninitialized_elements ("I know what I'm doing"). > I understand; the logic is the opposite here and analogous to initialization of single elements The idea is that you can be explicit about non-initializing elements. Always remember that neither use leads to uninitialized elements for types that cannot afford it. More about this is explained in the GitHub issue (August) * Many library functions and classes have lots of template parameters. > I'd advise using C++20 concepts (properly guarded in C++17 builds) to > improve error messages and document the requirements for each type. > This is a consideration for when the library is bumped to C++20; at the moment, I have annotated all the locations that will be replaced with requires clauses. The guarded alternative you propose adds too much noise to the code and forces the maintainance of two parallel concept systems. * I personally don't like unary operator+ for making copies. It's not > communicating > intent. I'd go for what numpy.ndarray does and call it array::copy(). > Actually, after the fact, I was informed that NumPy uses the same convention; unary + materializes an instance of the array. This is the dilemma with .copy(): it gives the impression that the library needs explicit .copy() to copy an array, implying that it needs an explicit mechanism to work around some sort of reference counting, which the library doesn't do anyway. All this is needed because of a limitation of auto rather than because of a technical need of the library. BTW, the function is called .decay() in the library. Giving two options, `+` or `.decay()` if you want to be more explicit. > * Subarrays and array references are not copyable. This is unusual, > since all reference > types I know of (span, mdspan, string_view, url_view, > mysql::rows_view) are copyable. > It looks like the library tries to make the type appear like a > reference, but > I don't think that's wise - exotic references are not language > references, > no matter how hard you try. > I would make subarrays copyable to avoid surprises. > Actually, making the reference types copyable leads to surprises in my opinion. This is addressed in the GitHub issue, and I added a new section called "Addressing subarrays". > > Maybe this is my lack of understanding, but subarray and array_ref seem > similar enough to be implemented using the same class. > array_ref has a simpler interface because it deals with continuous memory. You are right that they can be implemented mostly in the same way, and they are. > - What is your evaluation of the implementation? > > It's difficult to follow, and it has a non-trivial amount of technical > debt. > Yes, it is a complicated library to implement. Most of the points below are addressed in the Github issue (August) Some points to note: > > * include/ contains many files that are not headers. It contains docs, > build scripts, CMakeLists.txt and empty files. include/ shouldn't > contain any of this because it's installed with the library to the > consumer. > Some of the headers under "adaptors/" seem to be public API, others > seem to be examples or tests. > * There are many files containing commented leftover code and > #if 0 preprocessor blocks. > * There is an unscoped, undocumented NOEXCEPT_ASSIGNMENT macro in > array.hpp. > This needs either to be renamed to BOOST_MULTI_NOEXCEPT_ASSIGNMENT > and documented, > or (better) removed. > * Same with MULTI_USE_HIP (although I understand that this one may be > unavoidable). > * The min and max functions need to be guarded against macro substitutions. > * None of the examples seem to be built by CI, and some are not in the > CMakeLists.txt either. > They need cleanup and comments to explain what's going on. > * A considerable amount of the test suite is missing from the test Jamfile. > This is problematic because your main source of compiler coverage happens > by running b2, not CMake. > * "examples/" should be renamed to "example/". > * There seems to be an operator referencing dynamic_array_cast, > but I can't find this function defined anywhere. It seems to be mentioned > by the docs, but the function isn't there. > * What's the rationale behind implementing a custom tuple type? > The rationale is that std::tuple doesn't work on the GPU (__host__ __device__ etc), so I have to implement it from scratch. > - What is your evaluation of the documentation? > > As other reviewers mentioned, the reference needs to be reworked. > I won't insist here, since it's already been mentioned. > > Public adaptor code needs to appear in the reference, too. > Same for config macros that might be defined by the user. > > The discussion is useful and explains the rationales well. > I'd change the "Advanced usage" section title, since constructing > an array is not advanced usage. > The sections have been renamed, and the public interface is documented through MrDocs. > I'd also try to introduce concepts incrementally. > For instance, slicing should probably come before assignment, > since you use slicing to discuss assignment. > I feel that I can't delay the assignment section too much, so what I do to address this is to just explain what the syntax uses does and refer the reader to a later section for a full explanation. > > > Some minor points: > > * I'd advise using snake_case for variables in the examples. > That is what I am doing in general; maybe I changed this already. I feel that saying things like A2D or A2 is ok; A_2D would be too verbose. * https://correaa.github.io/boost-multi/multi/tutorial.html#tutorial_init > Prefer std::unique_ptr to raw new and delete in the examples. > I think it will distract from the main point: First, it will not make it safer because then the scope of the array references will not be delimited to a clear delete, Second, typical uses of array_ref involve legacy code that doesn't manage memory automatically Third, I will have to use .get() to get the raw pointer. > * Some sections refer to the "std::mdspan proposal". It's already in the > standard, so this should be updated. > I can't find myself referring to "std::mdspan" as a proposal; maybe I changed this already. > * The BIP example in the interoperability section seems to contain > unbalanced scopes (unmatched '{}' characters). > The scopes are balanced; there was a stray commented "}" that could be causing confusion. * > https://correaa.github.io/boost-multi/multi/interop.html#interop_substituta… > " In a departure from standard containers, elements are left > initialized..." should be uninitialized. > fixed * > https://correaa.github.io/boost-multi/multi/tutorial.html#tutorial_slices_a… > "Other notations are available, for example this is equivalent to > A(multi::" contains a rendering error. > fixed * > https://correaa.github.io/boost-multi/multi/interop.html#interop_serializat… > "Large datasets tend to be serialized slowly for archives with heavy > formatting. Here it is a comparison of speeds when serializing and > deserializing a 134 MB 4-dimensional array of with random double > elements." > Should be "Here is..." and "4-dimensional array of random double > elements". > Fixed, and similar problems like "Here it is" * "Gettings started" should be "Getting started" in the nav bar. > fixed * reinterpret_cast_array is mentioned in the docs but it does not exist. It is now documented as "yields a view of the subarray where elements are reinterpreted as a different type (elements must have compatible size)" > > - Did you try to use the library? With which compiler(s)? Did > you have any problems? > > I've run some of the examples in the docs in my Ubuntu 24.04 > machine with clang-22, C++23, libc++ and CMake in Debug mode. > No problems aside from the fmtlib problem with subarrays already discussed. > I would like to see the compilation error you get, here or in godbolt. > > - How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? > > I've read the documentation, cloned the library, scanned the source code > for > things that called my attention and built some toy examples. I haven't > delved into the GPU adaptors because it's outside my knowledge. > I've spent around 8h with the review. > Thank you; that is a lot of work, and I take your review seriously, and I apologize for missing it initially. > > - Are you knowledgeable about the problem domain? > > Not an expert. I've done some very basic scientific programming in C++. > My main expertise is networking. > Thank you again > > > Affiliation disclosure > > I'm currently affiliated with the C++ Alliance. > > > Ensure to explicitly include with your review: ACCEPT, REJECT, or > CONDITIONAL ACCEPT (with acceptance conditions). > > My current recommendation is to REJECT the library at this point. > This is not a hard rejection. I'd like to see this library being reviewed > again > in 2-3 months, when the points raised in the review are fixed. Similar to > what we did with Boost.Decimal. I was close to recommending > conditional acceptance though, so please keep up the good work. > Thank you, Rubén; your insight will always be welcome, whatever the outcome. Please let me know if you have any questions. Alfredo

1 0

shout out to Gennaro Prota
by Robert Ramey 07 Aug '26

07 Aug '26

A few weeks ago Gennaro took over the maintenance of the Boost Serialization Library. I've been following his work on addressing a large backlog of issues and PRs. The reason there's such a backlog is that many/most of them are quite subtle and many are edge cases. My handling of these was to spend a little time on them and conclude - whoops this is non-trivial - I'll have to address it later when I have time. My assessment hasn't changed. But I'm really impressed with how many he has addressed in a serious and definitive manner. I'm very optimistic about the future of the Boost Serializaton library. I never imaged that it wouldn't be standardized by now. Now I see why - Here's to another 25 years of the Boost Serialization library. Congratulations to Gennaro for taking this on and being so successful at it. Robert Ramey

4 3

[boost][int128] Formal Review Result
by Arnaud Becheler 05 Aug '26

05 Aug '26

Dear Boost Community, As Review Manager for Candidate Boost.Int128, I have carefully reviewed and incorporated the community's feedback from July 22–31. I decided to ACCEPT Boost.Int128 into Boost. The library's well-defined scope, clear design, its excellent documentation, its proven track record in the wild (including in Boost.Decimal and in production codebases on multiple platforms, tested on bare metal), the author's responsiveness throughout the review, and the fact that all review issues/PRs have been tracked with the "Boost Review" label, resolved (see: https://github.com/cppalliance/int128/pulls?q=is%3Apr+is%3Aclosed+label%3A%… ), and merged on develop convinced me to accept the library. Every reviewer who cast a formal vote recommended acceptance, and the only conditional verdict rested on bugs that Matt resolved (and one feature request he could not: https://github.com/cppalliance/int128/issues/485 ). As for the details: ACCEPT (7) Rainer Deyke (July 27) (Undisclosed) John Maddock (July 27) (Undisclosed) Christopher Kormanyos (July 27) (collaborator with the author; not C++ Alliance) Pavel Pavlov (July 28) (Undisclosed) Peter Turcan (July 28) (C++ Alliance) Jamie Allsop (August 1) (Undisclosed) Nigel Stewart (August 1) (Undisclosed) ACCEPT CONDITIONALLY (1) Guillaume Dua (July 28–30) (Undisclosed) COMMENTS / NOT A FORMAL REVIEW Andrzej Krzemienski (August 2): on library-vs-builtin type semantics. Various Reddit reviewers (eisenwave/WG21, James20k, MarekKnapek, and others) contributed substantive technical feedback without a formal verdict. Jarod on French Discord: contributed a bug report without a formal verdict. NOTE: I also note that several reviewers and commenters appreciated that the library was available through a single-header aggregated file included by Compiler Explorer, making it extremely easy to experiment with, stress the implementation and review. I sincerely think this should become the norm, not the exception for future (small-ish?) libraries. The cost of aggregating the headers in CI is trivial and the benefit shows up in the numerous latent bugs surfaced by reviewers. CONCLUSION AND THANKS: Congratulations to Matt Borland on an excellent contribution, and my sincere thanks to everyone who took the time to review, test and debate. I must insist that identifying all those bugs early will make life infinitely easier for users and maintainers. Your time and effort are greatly appreciated. Have a wonderful week, Best wishes, Arnaud Becheler, Review Manager for Boost.Int128 ... and hopeful future Review Manager for Boost.256 ? ;)

3 2

[release] Master branch is closed for the 1.92.0 release
by Ion Gaztañaga 05 Aug '26

05 Aug '26

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

1 0

[multi] Multi Mini Review Begins Thursday
by Matt Borland 03 Aug '26

03 Aug '26

Hello, This is an announcement that the mini review of Multi [1] will begin on Thursday (August 6) and run through next Tuesday (August 11). The focus of this review will be the documentation, as that was identified as the weak point in the review earlier this year. This is the last scheduled review, so streak of reviews is nearly over. Thank you all for your participation. Matt Multi Review Manager [1] https://github.com/correaa/boost-multi

1 0

[boost][int128] Formal Review Is Now Closed
by Arnaud Becheler 03 Aug '26

03 Aug '26

Good morning Boost Community, After a small extension over the weekend to allow potential reviewers to chime in, I am happy to declare that the Formal Review of Candidate Boost.Int128 is now closed! I will summarize the exchanges, count the votes and issue a statement in the next few days. I want to thank everyone who took part in the review and discussions, both on this mailing list and on other networks (Slack, Reddit, LinkedIn, Discord...): this was very helpful for both the Review Manager and the author. It is quite formidable to see what an open-source community can put together! Reviews like this are the closest thing C++ has to a sports team, and that was a very clean game :) Have a great week, Best wishes, Arnaud Becheler, Review Manager

1 0

[boost][int128] Formal Review Begins Today (July 22-July 31)
by Arnaud Becheler 02 Aug '26

02 Aug '26

Dear Boost Community, I am very happy to open the Formal Review period for Candidate Boost.Int128 authored by Matt Borland, running from today, July 22nd to July 31st 2026. Int128 is a portable C++14 implementation of signed and unsigned 128-bit integers. It has no dependencies, is header-only, and can be consumed as a module in C++20. You can find the library and its documentation here: - https://github.com/cppalliance/int128/tree/boost_review - https://develop.int128.cpp.al/overview.html I could make examples work in Compiler Explorer: https://godbolt.org/z/5aM6K9b4r Although possibly not faithful to Matt's implementation, this CE link will be handy if you are in a rush but want to play with the library. Candidate Boost.Int128 serves as a practical solution to the partial (resp. absent) support of 128-bit integers by gcc/clang (resp. msvc), and as an alternative to projects with a heavy dependency footprint. For example Boost.Multiprecision offers 128-bit integers but drags 25 Boost modules which may not be acceptable when only a single type is required. We can expect this new lightweight library to interest anyone manipulating integers beyond the 64bit numeric range, for simple problems like when summing many 64-bits integers in an accumulator, computing a*b/c where the intermediate product overflows 64 bits, or in complex fields like cryptography, hashing, random number generation, precision arithmetic... Note: Due to the Boost release cycle, the master branch is frozen on all Boost projects. This had the inconvenient effect of preventing Matt from operating a cross-repo PR to enable GPU support with Boost.Charconv. Due to the lack of a practical solution, the CI on master will remain red until 1.92 ships. We kindly ask reviewers to focus on the boost_review branch. As always, we welcome all reviews, from quick impressions to detailed analysis. Your feedback helps ensure that the library meets Boost's high standards for correctness, performance, documentation, and design. If you’re interested in contributing a review, please post to the Boost mailing list during the review period. In your review please state whether you recommend to REJECT or ACCEPT the library into Boost, and whether you suggest any conditions for acceptance. Other questions you might want to answer in your review are: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? 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 problems tackled by the library? Thank you for your time, Have a wonderful week, Arnaud Becheler, Review Manager Boost.Int128

11 20