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@lists.boost.org> wrote:
Send Boost mailing list submissions to boost@lists.boost.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to boost-request@lists.boost.org
You can reach the person managing the list at boost-owner@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@gmail.com> Subject: [boost] [container] Boost.Container is header-only again in develop (and hopefully, in 1.93) To: boost@lists.boost.org Message-ID: <a4457a51-a820-449e-8ba8-9ba49520a9fb@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@gmail.com> Subject: [boost] The State of Boost at CppCon To: "Boost developers' mailing list" <boost@lists.boost.org> Message-ID: < CAOLveGFujWk_ux+uJduCqmoR1jo7CPmycik6icddb2JtQY64MA@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@gmail.com> Subject: [boost] Re: The State of Boost at CppCon To: "Boost developers' mailing list" <boost@lists.boost.org> Message-ID: <CAG3ZVmqNaZ1XqJG=MCOdfWm_npbK+cmfrqAr= f2MKxLuk5H4Ew@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@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@lists.boost.org To unsubscribe send an email to boost-leave@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/I2V3NI4Y...
------------------------------
Message: 4 Date: Mon, 31 Aug 2026 18:38:53 -0400 From: Harold Bott <haroldjbott@gmail.com> Subject: [boost] Re: The State of Boost at CppCon To: "Boost developers' mailing list" <boost@lists.boost.org> Message-ID: < CAOLveGHtV824gsYRuxiHOKSpD4npoUgCT4Tw0h3F_PzgB2U1ew@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@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@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@lists.boost.org To unsubscribe send an email to boost-leave@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/I2V3NI4Y...
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@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/DBA44ZDJ...
------------------------------
Subject: Digest Footer
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
------------------------------
End of Boost Digest, Vol 7854, Issue 1 **************************************