- Boost - lists.boost.org

Capy: Request for endorsements
by Vinnie Falco 30 Jan '26

30 Jan '26

Hi. We are proposing a new library "Capy" as a candidate library and seeking endorsements for formal review: https://github.com/cppalliance/capy https://master.capy.cpp.al/capy/index.html This library provides facilities which use C++20 coroutines to perform I/O. It is not a networking library, yet it is the perfect foundation upon which networking libraries, or any libraries that perform I/O, may be built. It introduces concepts for representing buffers of data, and moving those buffers of data through processing pipelines driven entirely by C++20 coroutines. The design of the library is based on one simple observation from Peter Dimov: An API designed from the ground up to use C++20 coroutines can achieve performance and ergonomics which cannot otherwise be obtained. Capy is currently the foundation for another new library (not yet proposed) called "Corosio" https://github.com/cppalliance/corosio https://master.corosio.cpp.al/corosio/index.html Corosio is a complete portable networking library which is built on the facilities that Capy offers. We intend to propose this library soon as the successor to the immensely popular Boost.Asio library. Capy is also the foundation for yet another new library (not yet proposed) called "Http" https://github.com/cppalliance/http https://master.http.cpp.al/http/index.html The Http library uses Capy, yet does not use Corosio. That is because Http is "Sans/IO." It provides the algorithms and data structures which implement the HTTP protocol at a high level, while remaining agnostic to the particular network implementation. This is possible thanks to the powerful stream abstractions which Capy offers. Capy is also used by Beast2, which is yet another new library (not yet proposed) and also the name for a family of libraries: https://github.com/cppalliance/beast2 Beast2 uses the Capy, Corosio, and Http libraries to implement high-level HTTP servers written in a C++ version of Express JS routers. This is the successor to Boost.Beast (which will continue to be maintained independently ). The Beast2 family of libraries includes: Capy — The library currently being proposed, the foundation of I/O. Corosio — Coroutine-only portable networking. This is the successor to Boost.Asio. Http — Sans-I/O HTTP/1.1. This is a high-level library: servers, clients, Express JS middleware. Websocket — Sans-I/O Websocket. This is also a high-level library. Beast2 — High-level HTTP and WebSocket servers. Express.js-style routing Burl — High-level HTTP client. curl features, coroutine ergonomics of coroutines, and Python Requests inspired API Currently, the C++ Standard does not deliver facilities optimized for networking I/O. We believe that Capy should become a standard library component to fill this gap. Our first paper based on Capy, introduces the " IoAwaitable" family of concepts: https://github.com/cppalliance/wg21-papers/blob/master/source/d4003-io-awai… The Beman Way We are bringing Capy to Boost because this is what Boost was created for. The project exists to incubate high-quality libraries destined for standardization. Beman Dawes founded Boost on the principle that the best path to the standard is through proven practice: build it, ship it, let users depend on it, learn from real-world feedback, then propose standardization. Smart pointers, regular expressions, filesystem, threading primitives—all followed this path from Boost to the standard library. Capy represents Boost returning to its role as a leader in C++ standardization efforts. The library addresses a real gap in C++26: there is no standard foundation optimized for coroutine-based I/O. Rather than waiting for a committee to design something in the abstract, or adapting networking to a framework built for different requirements, Capy takes the proven approach. It exists. It works. It powers real networking code today. Now it needs the scrutiny and refinement that only the Boost review process can provide. The Problem Capy Solves When an I/O operation completes, the operating system wakes up some thread, such as a completion port thread, an epoll reactor, or an io_uring worker. Without affinity tracking, your coroutine resumes on that arbitrary thread, forcing you to add synchronization everywhere or risk data races. This is the fundamental problem that coroutine-based networking must solve. Capy's answer is the IoAwaitable protocol. When you launch a coroutine with a designated executor, every child coroutine inherits that executor affinity automatically. Execution context flows forward through `co_await` chains, not backward through P3826 queries, to ensure every coroutine in the chain runs in the same context. When I/O completes on some OS thread, the IoAwaitable protocol ensures your coroutine resumes on its designated executor. The data flow is explicit and testable. There are no thread-local globals, no implicit context, no surprises. Capy's `task` type uses the compiler to enforce invariants. Cancellation follows the same forward-propagation model. Stop tokens flow forward from the launch of a coroutine chain alongside the execution context, to arrive at the platform API boundary, providing a uniform cancellation interface across all operations. Frame allocation is where coroutine overhead traditionally hurts performance. Capy addresses this with thread-local recycling pools that achieve zero steady-state allocations after warmup. The coroutine launch site controls allocation policy, enabling per-deployment customization: bounded pools for real-time systems, per-tenant budgets for multi-tenant servers, or tracking allocators for debugging. Buffer handling is essential for networking, and Asio's twenty five years of experience showed us how. Capy provides buffer sequence algorithms: think `std::ranges` but for buffers. These are the vocabulary types and operations that networking code needs: slicing, copying, concatenating, and iterating over discontiguous memory. One million scatter/gather buffers, if you will. The design is driven by real-world usage, not theoretical completeness. Capy is opinionated on the things that matter for I/O: - An executor model for coroutine affinity and completion dispatch - Stop token integration: uniform cancellation, always available - Allocator control over frame allocation with zero-overhead recycling - Forward propagation of the full context through every `co_await` - A `task` type that enforces the _IoAwaitable_ protocol at compile time - Composition primitives for launching and coordinating coroutines - A strand for safe concurrency without mutexes - Buffer sequences: `std::ranges` for untyped bytes - Type erasure by default: no combinatorial explosion of templates Proven Through Corosio Capy is not speculation. It powers Corosio, a coroutine-only networking library that we are developing together. Corosio provides real sockets, acceptors, TLS streams, timers, DNS resolution, and multiple implementations of SSL streams, all built on Capy's foundation. This is the successor library to the incredibly popular Boost.Asio. It demonstrates what networking could look like if designed for coroutines from the start rather than adapted from callback-based models. The standardization strategy follows from this layering. Capy is the foundation piece that belongs in the standard: executor model, task types, buffer algorithms, cancellation integration. These are stable abstractions that networking libraries can build upon. Corosio, the networking piece, can remain outside the standard to mitigate risk: sockets and protocol implementations typically experience difficulty achieving consensus even after years of committee attention. Corosio can mature externally where it can evolve based on user feedback, while Capy provides the stable foundation that the standard library lacks. Call to Action We are requesting endorsements from Boost members to proceed with formal review. If you believe that Boost should provide a foundation for coroutine-based I/O—and that proven practice is the right path to standardization, your endorsement would be welcomed. The team is also happy to receive feedback on the design, the implementation, and the documentation. The library is ready for serious evaluation. Clone it, build it, write code against it, and tell us what works and what does not. This is Boost doing what Boost does best: building the libraries that C++ needs, proving them in practice, and paving the way for standardization. Distributed under the Boost Software License, Version 1.0. (See accompanying file [LICENSE_1_0.txt](LICENSE_1_0.txt) or copy at https://www.boost.org/LICENSE_1_0.txt)

1 0

Boost Version 1.90.0 Release report
by rob＠cppalliance.org 26 Jan '26

26 Jan '26

Apologies to everyone for the delay in this release. We had multiple technical issues to work out related to the new Mailman as well as some other technical issues. We've also added some new data points of interest! As always, this is a work in progress, it will continue to grow and be refined. Suggestions and ideas are always welcome! https://downloads.cppalliance.org/reports/boost_1_90_0_release_report.pdf

1 0

[Boost.Multi] Initial feedback
by Andrzej Krzemienski 25 Jan '26

25 Jan '26

Hi Everyone, Given the recent announcement of the upcoming Boost.Multi review, I wanted to offer some initial feedback. I would like to thank Alfredo for writing and sharing the library. I would also thank you for the single header version and the Compiler explorer integration. This is so welcoming not only for the users but also for the reviewers. I am not well familiar with the domain.i only had a look at the docs and played with toy examples in Compiler Explorer. I would like to request a Design Rationale section that would address some of the questions up front and bring some insight into the domain: 1. Is it a common need in the mentioned application fields to add a new dimension to the already stored N-dimensional data? If so, could we see an example of how to do it? 2. Why is c++17 chosen as the minimum? 3. The number of dimensions is static, but the sizes in each dimension are dynamic. Can you provide the rationale for this choice? The design: 1. I am still trying to digest the way by-reference and by-value is handled in the library in the presence of the "ref"/"view" types. It looks like the simple advice for the new users would be: * Always use `auto& ref = x` if you need the reference semantics, where `x` is whatever expression. * Always use `auto val = +x` if you need value semantics, where `x` is any expression. It looks like it is optimum even when `x` is of type `array`. 2. The initialization from values is too similar to the initialization from extents. I cannot easily figure out which initialization is used in `multi::array a({3, 4, 5});`. This is error-prone. I would prefer a longer: `multi::array a(multi::extents{3, 4, 5});`. On the other hand, does the initialization from small manual static sets of data happen often? I would think that for these use cases you would read the data from some external source. 3. If the docs recommend that all functions should be generic to account for subarrays and refs, then this library could offer a concept like `Indexable<Dimensionality, ElementType>` available for C++20 compilers. 4. Are sizes equal to strands? Does .elements() offer contiguous access? 5. For the initialization, did you consider factory functions or tag parameters? ( https://akrzemi1.wordpress.com/2016/06/29/competing-constructors/) The differentiation of meaning by braces/parens seems easy to misinterpret. 6. All the subarrays and dynamic_arrays have function swap, but it is not documented. Does it have a precondition that sizes should match? Documentation: 1.It is very clear already! 2. In the introduction it is worth explaining the term "stride-based layout" or link to the definition. This concept seems crucial to the library. 3. The docs say "or tensors in the 3D case". Tensors are arbitrary dimension. 4. I think that in real, practical use cases the array data is populated from files or datastres rather than from literals (compile-time values in braces). Could the tutorial demonstrate the endorsed way of doing such data population with this library? 5. I really appreciate that you prefix names with `multi::`. The examples could also mention the headers that you need to include. The initial docs examples may be the place where I will learn the headers. 6. The interface discoverability is not great: I wanted to quickly check the contract of `array::elements()`. I cannot find it. The reference section only has repeated text "same as for dynamic_array" (no link). Generally, the "redirect" philosophy in the reference documentation is mean.In order to look up the semantics of array::operator(), I am redirected: first from `array` to `dynamic_array`, then to `array_ref`, and only then to `subarray`. 7. Generally, we need to see a more detailed Reference section. For instance, what is the return type of operator[]? 8. Document if `array` and siblings can have dimensionality 0 (which would mean access to a single element). 9. It is strange to see a section titled "Static arrays" that describes type `dynamic_array`. In C++ "static" and "dynamic" tend to have opposite meanings. Regards, &rzej;

2 10

[boost][multi] Feedback on `restrictions`
by Andrzej Krzemienski 25 Jan '26

25 Jan '26

Hi All, "Restrictions" (lazy arrays) in Boost.Multi look like a useful and practical component. The below feedback may sound negative, but it should be treated as suggestions for improving the feature. I find the name "restriction" surprising. Is this a term of art? "Lazy array" immediately conveys the idea, so I wonder why you decided to go with "restriction". I already complained that the "Reference" section is not serving its purpose well. Regarding "restrictions", they are simply missing from that section. Having read the tutorial, and wanting to use the feature in my program, I need to know: 1. Which header to include 2. What is the type returned by the "wedge" operator 3. Is the return type something that I should be able to name, use? Or is the contract "just assign the result to your array, and don't ask for the type name"? 4. What are the preconditions of the operation? 5. Are there things that I can do wrong when using the function and resulting types? 7. Does the function that I provide need to have the same number of arguments as the number of dimensions in the `extents` that I provide? 8.Do you guarantee that the index values that will be passed to subsequent invocations of my function will come in specific order? Or do I need to make sure that my function is pure/regular? 9. Does the function that I provide need to be copyable? 10. Header `restriction.hpp` has functions `make_restriction()` defined. Are they intended for users? If so, they need to be listed in "Reference"' also. I question the choice of using an arbitrary operator for creating lazy arrays. It makes the user code difficult to read and understand. I imagine that in my company I assign a junior developer to fix something in the code, and they are exposed to these bitwise-xor operators. This is an unnecessary confusion. A named factory function like `make_lazy` would immediately sell the intent: it combines the extents with an "indexes-to-value" function to produce a lazy array. It looks like there is an implied concept in your library, "non-mutable array access"., which probably includes being the RHS of the assignment to a "mutable array access". Now I feel even stronger that it should be given a name and be defined, even if semi-formally. The tutorial for restrictions mentions the function ".home()". Is this intended to be part of the library's interface? If so, it must appear in the "Reference" section. The Reference section defines what is the intended interface of the library as opposed to declarations that happen to exist in the headers for other reasons: as temporary solutions, implementation details, experiments or artifacts. Regards, &rzej;

2 6

Fwd: [Boost.Multi] Initial feedback
by Andrzej Krzemienski 23 Jan '26

23 Jan '26

Forwarding my private reply to the entire group... ---------- Forwarded message --------- Od: Andrzej Krzemienski <akrzemi1(a)gmail.com> Date: czw., 22 sty 2026 o 09:50 Subject: Re: [Boost.Multi] Initial feedback To: Alfredo Correa <alfredo.correa(a)gmail.com> czw., 22 sty 2026 o 04:08 Alfredo Correa <alfredo.correa(a)gmail.com> napisał(a): > On Wed, Jan 21, 2026 at 1:56 PM Andrzej Krzemienski <akrzemi1(a)gmail.com> > wrote: > >> >>>> What do you mean by contract? >>> >> >> All the characteristics that are usually described when documenting the >> Standard Library functions: >> https://cppreference.com/w/cpp/utility/optional/transform.html >> >> Like: return type, constraints, const/constexpr properties, >> postconditions. >> In this case, I was interested in what properties the returned range has: >> random-access, contiguous? I naturally expect that it is a contiguous range >> for multi::array and multi::array_ref, so I wanted to confirm that. I >> suppose it is different for subarrays. I can hardly imagine they would have >> the same range category. >> > > return type: A custom `elements_type`, which is a random access range. > for `multi::array` the type is `multi::subarray<T, 1>` because it can be > contiguous. > > no contraints, .elements() always returns something valid, even if the > array is empty. > it is constexpr. > postcontions, nothing changes, .elements() is just another view. > > I say this now: "As an alternative, the elements can be iterated in a > flat manner, using the `.elements()` member. > This "elements" range also provides the `begin` and `end` iterators > (`.elements().begin()`) and indexing, in the canonical order of the > original arrays (rightmost index changes fastest). > The elements range is always random-access, but it can be contiguous > depending on the original array (`multi::array` generally give contiguous > element ranges.)" > > In the reference section, > ``` > | `elements` | a flatted random-access > view of all the elements rearranged canonically. `A.elements()[0] -> > A[0][0]`, `A.elements()[1] -> A[0][1]`, etc. The type of the result is not > a subarray but a special kind of random-access range. Takes no arguments. > ``` > > And, later for array_ref, > ``` > | `elements` | a flatten random-access and contiguous view of all > the elements in the array in canonical order. (This is overwritten from the > base class, to provide contiguous access) > ``` > Ok, so about these `elements()`: 1. Regarding the array_ref member, I request that you specify this more formally: that the returned type models the concept std::ranges::contiguous_range. This already implies that it is random-access. A range need not be copyable, if you want this to be part of the guarantee, say that the return type is a view that models std::ranges::contiguous_range. 2. Regarding the array member, the fact that it might be contiguous is also a useful guarantee. Could the docs be more specific under what circumstances I get a contiguous range? Regards, &rzej; > I also added that all member functions are constexpr unless specified > differently. (almost all member functions are constexpr, a couple of > exceptions is some destructors and some constructors, due to C++17 > limitations). > > >> >> >>> >>> The search box leads me to: "a flatted view of all the elements >>> rearranged canonically. A.elements()[0] → A[0][0], A.elements()[1] → >>> A[0][1], etc. The type of the result is not a subarray but a special kind >>> of range. Takes no argument." >>> >> >> It takes me to subarray::elements, but that doesn't imply that >> array::elements would have the same contract. >> "special kind of range" is not the level of detail that I expected. I >> think you owe the user the range category. >> > > range category: always random access, contiguous for multi::array. > > Thanks, > Alfredo >

2 1

Moving boost/static_assert.hpp to Config
by Peter Dimov 23 Jan '26

23 Jan '26

As discussed last time, Andrey Semashev and I moved boost/static_assert.hpp from StaticAssert to Config in order to reduce nearly everyone's dependencies by one (there's no point pulling an entire repository for just one header file.) However, this presents some issues going forward. If I change depinst.py to properly "know" that boost/static_assert.hpp is now in Config, a lot of things break. That's because many libraries list StaticAssert as a dependency in their build.jam and CMakeLists.txt files, and since it's no longer used, depinst doesn't install it and there are errors. We could in principle go over all these (there are ~54 of them) and fix them, but in my experience, changes that break things internally for us also usually break things for others as well. So... instead, we could name the Config header boost/config/static_assert.hpp, leave boost/static_assert.hpp in StaticAssert, and have it include the Config one. This is going to be a lot less painful; people who care about the dependency would change their includes, whereas those who do not, will not. Opinions?

6 20

Intro & Request for Boost Stories
by Mark Cooper 21 Jan '26

21 Jan '26

Hello everyone, I'm Mark Cooper, CMO at The C++ Alliance. I just wanted to introduce myself, and let you know that I'm always looking out for new examples of how the community is building / using Boost. So if you're working on anything that you think the C++ world would find interesting, send me an email at mark(a)cppalliance.org. Thank you, Mark

1 0

Boost Libraries are Obsolete
by Vinnie Falco 18 Jan '26

18 Jan '26

I believe some Boost libraries become obsolete by newer versions of C++. For example, boost::filesystem, Boost.CharConv, and Boost.Variant could be considered obsolete in versions C++17 and later as these facilities are in the standard. It can be tricky to figure out what is obsolete. Is boost::shared_ptr obsolete in C++11? Probably not since it has features not found in the standard. Anyway, I'm not trying to figure this out for all the libraries. For boost.org it might be nice to let users specify the "minimum version of C++" which they use. And they can opt in to filtering the Libraries based on this minimum version. Someone who is using C++23 can choose not to see libraries like Boost.Align, Boost.Assign, or Boost.Atomic. We will need to add metadata to each library's repository to know the maximum version. What do you all think about this? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

6 8

Boost.Multi (multidimensional arrays) library ready to request a review
by Alfredo Correa 09 Jan '26

09 Jan '26

Hello Boost community, I want to propose Boost.Multi, a modern C++ library for owning and non-owning multidimensional arrays with STL-compatible iteration, slicing, layout control, and lazy arrays/expressions. (The library requires at least C++17) I previewed the library on this mailing list before (see archives), but it is ready for review now and includes a couple of new features (such as lazy expressions, by popular demand) and much more comprehensive documentation. The library is built on current uses (at least two production codes) and on past experience (such as Boost.MultiArray, Blitz, Eigen, and std::mdspan). While mdspan provides a powerful non-owning view abstraction, Boost.Multi focuses on ownership, views, expressive multidimensional manipulation, and generic programming (STL-like iteration and algorithms, allocators, Ranges, Thrust). It is aimed at, but not limited to, numerical, scientific, and HPC-style workloads and emphasizes interoperability. The library has been in active use and refinement for some time, and it may now be ready for Boost review. I would be very grateful for: * Feedback on whether the library is suitable for Boost * Endorsements from those willing to support a formal review. I have an early endorsement from @Vinnie Falco, but additional endorsements are welcome * Guidance on the following steps to start the review process Repository: (Gitlab or Github mirrors, whatever you find more convenient) https://gitlab.com/correaa/boost-multi https://github.com/correaa/boost-multi Documentation: https://correaa.gitlab.io/boost-multi/multi.html https://correaa.github.io/boost-multi/multi.html If you encounter issues before a format review, the most efficient way would be to open an issue on GitLab or on GitHub: https://gitlab.com/correaa/boost-multi/-/issues https://github.com/correaa/boost-multi/issues Impatient? You can download the core library as a single header file https://correaa.gitlab.io/boost-multi/boost-multi.hpp (nightly updated) or try it in Godbolt: https://godbolt.org/z/KxGoP5Kq9 Want to check if it works with your favorite compiler? (probably it does, check compliance here: https://godbolt.org/z/fz6f6erq1) Want to test GPU capabilities? Please get in touch with me. What to chat? Join the Slack channel: https://cpplang.slack.com/archives/C071VGKUA5P Thank you all very much for your time and for maintaining such a valuable ecosystem. Best regards, Alfredo

3 3

[Graph] Any interest in adding Nearby Neighbors greedy TSP tour heuristic?
by matt.egyhazy＠gmail.com 02 Jan '26

02 Jan '26

Hi, I wrote the original metric_tsp_approx in BGL a long time ago and had help from Andrew Sutton to make it 'BGL ready'. Given a bit of free time over the holidays, I became interested in making some modifications to the original (various cleanup / better test harness) and then later (after a side track with Christofides TSP heuristic, which I deemed too inefficient for its upper bound benefits) I became interested in implementing a basic LK (Lin-Kernighan) solution. To do so first requires a TSP tour as a starting point. I decided to write an implementation of the greedy Nearby Neighbors heuristic to create this initial tour, which I have done. Nearby Neighbors runs faster than the metric_tsp_approx but has more erratic solution (tour) performance. It also has some different characteristics as a local greedy solution vs. metric_tsp which creates an MST across the whole graph. Is there any interest from the group in taking this heuristic as well as the LK? The LK will perform more slowly than metric_tsp_approx and much more slowly than Nearby Neighbors but also (on average) generate better tours.

2 3