September 2026 - Boost - lists.boost.org

[container] CI errors and git issues
by Andrey Semashev 21 Sep '26

21 Sep '26

Hi, My Boost.Filesystem CI fails to checkout Boost.Container as a dependency on a few runners: Installing: core, exception, container, thread, iterator, bind, detail, timer, system, assert, smart_ptr, foreach, container_hash, test, range, config, throw_exception, utility fatal: reference is not a tree: fb208a12155fb57e5dd44e6ec22fae413f6a2966 Unable to checkout 'fb208a12155fb57e5dd44e6ec22fae413f6a2966' in submodule path 'libs/container' Error: The command 'git submodule -q update --init libs/core libs/exception libs/container libs/thread libs/iterator libs/bind libs/detail libs/timer libs/system libs/assert libs/smart_ptr libs/foreach libs/container_hash libs/test libs/range libs/config libs/throw_exception libs/utility' failed with exit code 256 Error: Process completed with exit code 1. https://github.com/boostorg/filesystem/actions/runs/35538790711/job/1061703… This is happening consistently on Ubuntu 16.04 runners but not others for some reason. I can't see the commit fb208a12155fb57e5dd44e6ec22fae413f6a2966 in my local develop, but there seem to have been a forced push. I'm guessing the commit is referenced by the superproject, and it's not getting updated? Also, I noticed Boost.Container git repository is in a permanently modified state: modified: include/boost/container/allocator.hpp modified: include/boost/container/node_allocator.hpp These files contain CRLF that are automatically converted to LF by git, making these files modified: $ git diff warning: in the working copy of 'include/boost/container/allocator.hpp', CRLF will be replaced by LF the next time Git touches it warning: in the working copy of 'include/boost/container/node_allocator.hpp', CRLF will be replaced by LF the next time Git touches it diff --git a/include/boost/container/allocator.hpp b/include/boost/container/allocator.hpp index 27fe145..6d7c183 100644 --- a/include/boost/container/allocator.hpp +++ b/include/boost/container/allocator.hpp @@ -288,7 +288,7 @@ class allocator void allocate_many(size_type elem_size, std::size_t n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; if(!dlmalloc_heap().multialloc_nodes(n_elements, elem_size*sizeof(T), dlmalloc::default_contiguous, &ch)){ boost::container::throw_bad_alloc(); } @@ -309,7 +309,7 @@ class allocator void allocate_many(const size_type *elem_sizes, size_type n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; if(!dlmalloc_heap().multialloc_arrays(n_elements, elem_sizes, sizeof(T), dlmalloc::default_contiguous, &ch)){ boost::container::throw_bad_alloc(); } diff --git a/include/boost/container/node_allocator.hpp b/include/boost/container/node_allocator.hpp index 9256946..0f6804c 100644 --- a/include/boost/container/node_allocator.hpp +++ b/include/boost/container/node_allocator.hpp @@ -271,7 +271,7 @@ class node_allocator void allocate_many(size_type elem_size, std::size_t n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; if(BOOST_UNLIKELY(!dlmalloc_heap().multialloc_nodes(n_elements, elem_size*sizeof(T), dlmalloc::default_contiguous, &ch))){ boost::container::throw_bad_alloc(); } @@ -286,7 +286,7 @@ class node_allocator void allocate_many(const size_type *elem_sizes, size_type n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; dlmalloc_heap().multialloc_arrays(n_elements, elem_sizes, sizeof(T), dlmalloc::default_contiguous, &ch); if(BOOST_UNLIKELY(ch.empty())){ boost::container::throw_bad_alloc(); This makes working with the repository a pain. Could this be fixed, please?

3 6

Capy and Corosio Review Results
by Jeff Garland 19 Sep '26

19 Sep '26

Boost.Capy and Boost.Corosio Review ResultRecommendation I recommend that *Boost.Capy and Boost.Corosio be conditionally accepted into Boost.* From my point of view the review participation was at the minimal tolerable participation level for acceptance. I did my best to try and recruit external participation to little avail. Many thanks to all the reviewers, but especially a few that went really deep to expose issues. The libraries of course comply with the basics of a good boost library in terms of layout testing and documentation. There were several testimonials to production utilization so speaks to usefulness. I think it's also clear that the library space in support of coroutines is disjointed -- and so this work makes a good contribution for users desiring coroutine-only concurrency solutions. The numbers look like: For *Capy*, *10 *primary reviews. - 5 ACCEPT - 3 CONDITIONALLY ACCEPT (1 changed from initial reject) - 2 reviews without a verdict - 1 private review without a verdict For *Corosio*, *7 *primary reviews. - 4 ACCEPT - 2 CONDITIONALLY ACCEPT - 1 review without a verdict To me, like with the original ASIO review, this represents a useful starting point - not an end. As the libraries evolve I would suggest repeated reviews diving into particular topics. Some of which I'll enumerate here. Context & Process I realize this took an extended period of time, but please understand that my process involved not just reading the reviews, but reading all of the documentation, writing code, and running tests. And, in particular, thinking about the design details and their overall sufficiency. My biases as a review manager include: 1) being the review manager of asio 20 years ago -- and having used it extensively and to this day in production code. The asio review was controversial and there were many doubts -- for me especially about the complexity. However, in the end -- that decision was clearly the right one in my view. 2) In my professional work having helped design and build a coroutine framework using elements of std, asio, beast, and our own. This framework is dramatically less ambitious than these two libraries and built strictly to need. 3) I'm not an author of any of P2900 or the follow-on works. But because of years of work on the committee, I have reviewed all the papers and appreciate what it is attempting to achieve. I have a working knowledge of the elements. For me, while Capy shares goals and elements of std::execution it takes a clear line of separation with the coroutine-only design. And I think it's perfectly fine for those two things to coexist in the world -- ideally sharing as much as possible. 4) My motivation for doing this work remains unchanged: to serve the best interests of the c++ community as best I can. In the following sections I will outline the recommended changes. In some cases where it's not clear the path forward I'll attempt to motivate further discussion. With the amount of discussion and material I'm sure I've made some incorrect recommendations here which we'll correct via discussion. Acceptance Conditions 1. Documentation rework There's a lot of documentation here. Several reviewers noted the difficulties with the docs -- especially in understanding the Capy design -- and I concur. It's possible some of these were already addressed as I saw some PRs happening during/after the review. Overall, this is unsurprising to me as async coding is really really hard. There's a lot of complex moving parts including threading and synchronization. And there are at least three audiences: - ordinary Capy/Corosio users; - authors of higher-level libraries using Capy; - authors implementing the coroutine/environment protocol for their higher level library The third audience in particular needs normative-level documentation of the rules. If it's there, it didn't really come through for me and clearly for one reviewer that attempted to us Capy directly for his use case. Some specific recommendations from various reviewers and myself: - Consider moving the Introduction to concurrency and C++20 coroutines outside of this documentation. While it's refreshing to see the tutorial on these things it distracts from the goal of these docs which is learning the library. Most of the topics discussed there (aka futures) aren't ever seen again in most of the library docs. Or at least move all that to the bottom so it's not 'the first section you read' by following the links. - Provide bare bones mental models from the various user perspectives up front or in the examples section. When looking at examples, things like 'strand' appear without any introduction. Since the Capy default is a simplified model I think that can be explained. I feel like a UML sequence diagram would bring a ton to understanding the component interactions. - Capy buffer sequences section seems odd in that none of the sub contents are shown in the TOC even though it's the same depth as the other sections. - Reduce the duplication of text and enhance the linkages. - Try to provide search even if it just run google search on the domain like cppreference. - Where is the linkage to Capy performance benchmarks? (see more in performance below). - The design section has 'Why not Cobalt?', 'Why not TooManyCooks', etc -- given where we are there should be 'Why not std::execution'. And while we're there there's an example that bridges the models users might be coming with some knowledge of std::execution. Pointers to papers that describe this are a valid approach. - thread_pool::destructor --> " Signals all worker threads to stop, waits for them to finish, and destroys any pending work items". I couldn't figure out what this means. Obviously it's calling the base class destructor which does shutdown() destroy sequence -- but that didn't clarify either. - io_result needs to be front and center in the Capy docs -- it is in the Corosio docs, but it's buried in the task section of the Capy docs. That is, of course, partially how it is used as an unnamed return value split into elements. Comments in some early examples with a link to the reference could help. - Capy: add a lifetime and ownership section covering the issues that users need to understand when composing Capy coroutines. - The consuming_buffers is listed twice in the index for Capy types - The Corosio Quick Start is at the end instead of the front? - The Corosio docs have a helpful Glossary, Capy does not. - The reference guides should break the typelists into layers/sections like: promise_types, buffer_types, stream_types, synchronization_types. Similar for Corosio. See also discussion of io_task versus task, etc in Minimalism. - Corosio: there is a lot of duplicate information in the documentation in the networking guide tutorial - Corosio: address the documentation comments in this review: https://lists.boost.org/archives/list/boost%40lists.boost.org/message/KHNY6… 3. Capy Naming - Concepts in Capy are mostly in CamelCase -- except for a couple that are inconsistently snake_case (*decomposes_to). - mutable_buffer_archetype_/ const_buffer_archetype_ -- what does the underscore mean? My take is that it's meant to be private and you use the aliases without underscore. 4. Corosio TLS TLS facilities should either be fully implemented and documented as safe for their advertised use, or unsupported/incomplete security functionality must fail safely and consistently rather than silently degrading security. 3. Performance and BenchmarksObviously the point of these libraries is high performance. During the review there was some extensive discussion of benchmarks, but there's nothing really for Capy -- just Corosio to Asio. But since Capy is in part a framework, maybe there could be a site for contributed benchmarks for libraries that build on Capy. On the Corosio side make published performance measurements reproducible and current, with sufficient information to understand the comparison. Required Discussion/Resolution before acceptance 1. Capy Design - Minimalism There's a significant discussion about pulling in various parts of Boost into Capy when they aren't required. There was some back and forth, but I found the results inconclusive for me to make a final directional suggestion beyond DynamicBuffer removal. This really needs a serious revisit to ensure unneeded features aren't shipped. It would be interesting to take the learnings from the downstream efforts outside what parts of Capy were actually needed. Let's talk about Capy::quitter versus task, io_task etc. When I started looking at examples I was perplexed about why I would choose one over the other and how I would integrate signal handling to do something useful like read several files in parallel. Then I found, not in the docs, but in the examples from the repo the 'quitter' example -- pretty much exactly the kind of thing today we'd write using asio. And if I'm just using coroutines it's clear from the example that outside of task Capy has other not well documented 'toolkit elements'. Looking at the code in the quitter example, well I wouldn't have guessed how to write that and the asio code would be more concise. So I think this goes to the heart of the question: why leave this stuff in if it's not really documented? And the reality of the split means that to do the asio equivalent for signal handling I have to write my own fairly ugly code as demonstrated in the example. 2. Overall Design - Splitting the Libraries The consensus seems to be that the separation of the libraries makes sense and I concur. However there are a number of detailed questions about the location of some facilities such as timing primitives that should be addressed. There's also an argument to break things down even further to allow reuse of useful synchronization primitives depending on all of Capy. *1a* Corosio: Delays and Timeouts There was discussion on this point including why this was a Corosio primitive and not in Capy. And the fact that there's allocations, etc. Being able to co_await on timers seems fundamental to me -- especially in a combined operation which is waiting on io or a timeout. *1b* Capy thread_pool What's wrong with boost.thread thread_pool was asked somewhere? Well really this type isn't so much a thread pool as an execution context (the base class). I'd suggest renaming to thread_pool_context or threaded_context clears up the confusion here. *1c* Adding to Capy - io_context and signal handling? From my professional experience writing servers purely with coroutines the io_context is the key to making signals, networking, file-io all go together smoothly. As such it seems like that fundamental construct should be in Capy. Let's take a use case of writing a command line tool to read a directory of files where I read and run a regex across each one to see if there's a match. Of course the user should be able to interrupt cleanly at any time. So we need a signal handler and a stop token to cancel work. Right now I think I have to use Corosio to do this when it seems this should be Capy only. This is basically the analog of an issue identified by another reviewer. Overall handling signals in a coroutine server is pretty essential and seems to be roll-your-own awkward for Capy. See also *Minimalism *section discussion of Capy::quitter. The Corosio io_context is really a simplification of the asio io_context the traffics directly in coroutine handles AFAICS. I'm unsure if this means Corosio's io_context should be redesigned and moved or if Capy should just have an independent facility. Of course feel free to explain why this isn't needed at all. *1d* splitting Capy into more parts I think there's an argument for this going forward, but I wouldn't push for this in particular right now. There are things like Capy::quitter (see below) that are promise types and buffer types that don't depend on the coroutines really. But I follow that there's a critical mass. Some of these smaller synchronization things might be good to push to the standard library. 3. The buffer problem I'm sure the following will cause a substantial amount of potentially harsh discussion (please start a separate email chain). However, I'm unpersuaded that the current design handles the buffer abstractions and buffer concepts correctly. (Note that reviewers in 2005 weren't all convinced of the asio design either). At a minimum I think this is a missed opportunity. While Capy has buffer concepts they are really less developed than the ancient boost.iostreams. In the end the concepts go unused in the Capy core and instead the asio derived mutable and const buffer types become the foundation. I'm sure there was a reason, but it feels ill advised. These two types are actually minimalist versions of std::span. They are pointers and size to the actual buffers with data. So for me at least this is an api usability issue: std::array<char, 1024> buf; auto buffer = capy::make_buffer( buf ); // make a view of the buffer not an actual buffer While I acknowledge Klemans comments in the discussion of this point, it is an unfortunate reality that some views necessarily become owning. Regardless, I'd be much happier if this api used the terms buffer_span or buffer_ref to clarify what the types mean. Even though that breaks from asio tradition the concept of a span was developed later. Now let's look at the actual dimensions of 'memory buffers' in programs. Dimension Examples Storage contiguous / scatter-gather Capacity fixed / dynamically extensible Access mutable / immutable Ownership unique owning / shared owning / non owning (view) Flow Direction source / sink / duplex Range type input, seekable, random access Consumption partial / all / incremental Lifetime ephemeral / retained There may be more, but I think a set of buffer concepts expressing many/most of these dimensions would be useful in expressing behaviors. Downstream in Corosio, of course, we find buffers that depend on these sorts of capabilities. Future considerations 1. A plea for a more interoperable ecosystem My future desire would be that Capy and Corosio continue exploring the concepts and factoring needed to provide greater interoperability with other libraries. This doesn't require every library to directly support every other library. It means finding small, useful boundaries where efficient adapters are possible, allowing applications to combine facilities from Asio, Cobalt, Capy, Corosio, std::execution, and future libraries -- rather than forcing a choice among completely mutually exclusive stacks. I believe the reviewers provided some hints and suggestions for directions, but as Peter Dimov pointed out it's a difficult problem that remains unsolved. Thanks all, Jeff

4 5

Boost website refresh launched
by rob＠cppalliance.org 16 Sep '26

16 Sep '26

The new boost.org is live. Same peer reviewed libraries trusted by planetary rovers and particle accelerators, now on a site rebuilt to help you find, learn, and ship them faster. What's new: • Refreshed look and easier navigation • New user profile pages • Badges for contribution and participation • Community posts filtered by page topic • Prominent site-wide search • Better library search and filtering Please take a look and we are happy to get any feedback!

7 7

[poly_collection] new unordered collections and article on library's internal design
by Joaquin M López Muñoz 14 Sep '26

14 Sep '26

Hi, I recently added unordered, stable collections to Boost.PolyCollection, internally based on boost::container::hub: * boost::base_unordered_collection * boost::function_unordered_collection * boost::any_unordered_collection * boost::variant_unordered_collection Tutorial: https://www.boost.org/doc/libs/develop/doc/html/poly_collection/tutorial.ht… Full reference: https://www.boost.org/doc/libs/develop/doc/html/poly_collection/reference.h… If you're interested, please play with these new collections and provide your feedback before official shipping (Boost 1.93). Available at https://github.com/boostorg/poly_collection (both develop and master). Thank you! Also, I wrote an article describing the internal design of the library: https://bannalia.blogspot.com/2026/09/inside-boostpolycollection.html Best regards, Joaquín M López Muñoz

1 0

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