- Boost - lists.boost.org

Capy, Corosio Review Failure
by Vinnie Falco 06 Sep '26

06 Sep '26

It is starting to look like the Capy and Corosio review outcome is not going to materialize. What are our options at this point?

8 9

Re: The State of Boost at CppCon (Harold Bott)
by Andrea Cassioli 03 Sep '26

03 Sep '26

Hi, this is my first message to the mailing list, and I hope it can help. I have been using Boost since early 2000s, at first mostly in academic project during my PhD and research activities, more recently working for a big logistic company. Over the years I have used several libraries (geometry, unordered, json among others), but the one I keep using over and over is Boost Graph. Its performance and extensive functionalities are still unparalleled. I see Boost as a "shadow standard library": it provides functionalities that are not yet part of the standard library, but they may one day. Or some libraries that are a bit too much of a niche to make it. Some other libraires can gain some performance boost with some additional work or assumptions (pun intended)! Boost is reliable and stable, and this is big plus in long running projects. However, all these qualities come with some drawback: - Some projects feel (or maybe are) stale or barely maintained, and as the number of library grows, some overlap. - The high standard of the code often means it is hard to contribute. - It is unclear what Boost is as a comprehensive library, why not make the single libraries indipendent. Boost is still a reference when it comes to C++ high quality libraries, but it can use some love and modernization, not just code wise but also in terms of process and connection to the users. Some work is under way and hopefully new life will flow in! Best, Andrea On Tue, 1 Sept 2026 at 00:41, <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. [container] Boost.Container is header-only again in develop (and > hopefully, in 1.93) > (Ion Gaztañaga) > 2. The State of Boost at CppCon (Harold Bott) > 3. Re: The State of Boost at CppCon (Robert Jones) > 4. Re: The State of Boost at CppCon (Harold Bott) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 1 Sep 2026 00:01:20 +0200 > From: Ion Gaztañaga <igaztanaga(a)gmail.com> > Subject: [boost] [container] Boost.Container is header-only again in > develop (and hopefully, in 1.93) > To: boost(a)lists.boost.org > Message-ID: <a4457a51-a820-449e-8ba8-9ba49520a9fb(a)gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > 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 > > ------------------------------ > > Message: 2 > Date: Mon, 31 Aug 2026 18:01:58 -0400 > From: Harold Bott <haroldjbott(a)gmail.com> > Subject: [boost] The State of Boost at CppCon > To: "Boost developers' mailing list" <boost(a)lists.boost.org> > Message-ID: > < > CAOLveGFujWk_ux+uJduCqmoR1jo7CPmycik6icddb2JtQY64MA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 > > ------------------------------ > > Message: 3 > Date: Mon, 31 Aug 2026 23:23:02 +0100 > From: Robert Jones <robertgbjones(a)gmail.com> > Subject: [boost] Re: The State of Boost at CppCon > To: "Boost developers' mailing list" <boost(a)lists.boost.org> > Message-ID: > <CAG3ZVmqNaZ1XqJG=MCOdfWm_npbK+cmfrqAr= > f2MKxLuk5H4Ew(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Well... I love Boost, but I'm very far from being any authority, so pinch > of salt and all that. > > I've used Boost since the C++98 era, and at that time I saw it very much an > incubator for what often became part of the STL. Bind, Lamda, Ranges, > Concepts etc. But since then, the STL and C++ language standard have become > a more structured effort (thank you Committee!), and that role for Boost > seems to have dwindled somewhat. I'm no longer quite sure what Boost > represents, although it's still an amazing repository. It seems to be one > among many now, rather the preeminent authority it once was. > > I shall view your presentation with great interest! > > Rob > > > > On Mon, 31 Aug 2026 at 23:05, Harold Bott via Boost <boost(a)lists.boost.org > > > wrote: > > > 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 > > _______________________________________________ > > 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/ > > Archived at: > > > https://lists.boost.org/archives/list/boost@lists.boost.org/message/I2V3NI4… > > > > ------------------------------ > > Message: 4 > Date: Mon, 31 Aug 2026 18:38:53 -0400 > From: Harold Bott <haroldjbott(a)gmail.com> > Subject: [boost] Re: The State of Boost at CppCon > To: "Boost developers' mailing list" <boost(a)lists.boost.org> > Message-ID: > < > CAOLveGHtV824gsYRuxiHOKSpD4npoUgCT4Tw0h3F_PzgB2U1ew(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Thank you, Rob. > > Will you be at CppCon? Please introduce yourself if you're there! > > -Harry > > On Mon, Aug 31, 2026, 6:24 PM Robert Jones via Boost < > boost(a)lists.boost.org> > wrote: > > > Well... I love Boost, but I'm very far from being any authority, so pinch > > of salt and all that. > > > > I've used Boost since the C++98 era, and at that time I saw it very much > an > > incubator for what often became part of the STL. Bind, Lamda, Ranges, > > Concepts etc. But since then, the STL and C++ language standard have > become > > a more structured effort (thank you Committee!), and that role for Boost > > seems to have dwindled somewhat. I'm no longer quite sure what Boost > > represents, although it's still an amazing repository. It seems to be one > > among many now, rather the preeminent authority it once was. > > > > I shall view your presentation with great interest! > > > > Rob > > > > > > > > On Mon, 31 Aug 2026 at 23:05, Harold Bott via Boost < > boost(a)lists.boost.org > > > > > wrote: > > > > > 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 > > > _______________________________________________ > > > 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/ > > > Archived at: > > > > > > https://lists.boost.org/archives/list/boost@lists.boost.org/message/I2V3NI4… > > > > > _______________________________________________ > > 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/ > > Archived at: > > > https://lists.boost.org/archives/list/boost@lists.boost.org/message/DBA44ZD… > > > > ------------------------------ > > 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 7854, Issue 1 > ************************************** >

2 1

[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