- Boost - lists.boost.org

is statsort ready to be part of Boost library?
by Peter Taraba 17 May '26

17 May '26

2 3

GitHub reliability
by Vinnie Falco 15 May '26

15 May '26

GitHub has become increasingly unreliable. I suggest the Boost project explore alternatives to be ready in case the need to move to a new hosted provider arises. We (the C++ Alliance) are investigating Codeberg. Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

14 33

[Boost.Graph] Survey: minimum C++ standard for Boost.Graph going forward
by Arnaud Becheler 14 May '26

14 May '26

Dear Boost Community, During the Boost Graph Modernization Workshop in Paris co-organized with Jeremy Murphy (BGL principal maintainer), one of the most frequent discussion points was the C++ standard version the Boost Graph Library should require. Some context worth knowing: - Boost.Graph is already C++14 - A lot of API modernization can be done without bumping the minimum. - Some modernization changes would land cleaner on a newer standard - We don't yet have a clear enough picture of our users' constraint space to inform our discussion about a potential baseline bump. For example, it appeared that automotive industry users will be locked in C++17 for a while with MISRA. Consequently we want to ask Boost.Graph users: What's the oldest C++ standard your project needs BGL to keep supporting (i.e. the version past which a bump would break you or force you to pin a version). Answers: C++14 / 17 / 20 / 23. You can answer: - with this simple Github survey: https://github.com/boostorg/graph/discussions/490 - on this reddit poll: https://www.reddit.com/r/cpp/comments/1tc1v6x/comment/olproye/ - or on this thread Also please indicate if you’re a BGL active user or an observer eager to give feedback (both are welcome!) Thank you for your time :D Arnaud

1 0

Fw: Re: Re: GitHub reliability
by Peter Taraba 14 May '26

14 May '26

1 0

Boost.Redis and Corosio
by Ruben Perez 12 May '26

12 May '26

Hi all, You might remember how I had started a prototype on how Boost.Redis would look like if it had a Corosio API some weeks ago. I have been improving the prototype until making it fully functional. You can find it here: Code: https://github.com/boostorg/redis/pull/417 Docs: https://anarthal.github.io/boost-redis-corosio/redis/index.html Marcelo has been performing benchmarks against the Asio API, with pretty good results: client | time ----------------------|-------- boost_redis_asio_co | 1.73 boost_redis_asio_cb | 1.35 boost_redis_corosio | 1.00 The benchmarks live in this repo: https://github.com/mzimbres/redis-cli-comp They measure total CPU time (rather than wall time) because the client is faster than the server, which gets saturated and becomes a bottleneck. Lower is better. Our idea is merging the pull request above to Boost.Redis if Corosio gets into Boost. This would make Boost.Redis support both Capy and Corosio. Because most of our code is written as state machines, the amount of duplication is pretty minimal. If interested readers find the time to have a look at the PR and leave some comments, I'd be thankful. On the other hand, I've also been writing a Corosio-based MySQL library. It is a fork of Boost.MySQL: https://github.com/anarthal/mycosql. It is functional, but still a work in progress. Why fork here instead of adding a new API to the library? Because the original Boost.MySQL is an older library (C++11), and forking would allow it to move to C++20 and update part of the API. But it also means more duplication. If things go well, I may propose it for Boost inclusion at some point. Kind regards, Ruben.

1 0

statsort
by Peter Taraba 09 May '26

09 May '26

1 0

PRs: Ubuntu toolchain PPAs on Drone CI
by Alexander Grund 06 May '26

06 May '26

Hi maintainers, I recently opened a PR for ~30 repos on Github titled "Enable adding Ubuntu toolchain PPA by default" and wanted to give some background. TLDR: This is an intermediate fix for Drone to avoid failures when an upcoming change in Boost.CI [3] is merged. The proper solution is to update .drone.star from e.g. Boost.CI [4], which has to be done by the maintainers who decide which configurations shall be tested The `.drone.star` CI config eventually calls `ci/drone/linux-cxx-install.sh` from Boost.CI [1] This, for a long time, added the ubuntu-toolchain-r/test PPA to be able to install older or newer compilers than available in the "default" Ubuntu repositories for the used image/container. However this is causing issues: 1. Overhead for adding and downloading from other sources 2. Additional (Avoidable) flakiness when Launchpad isn't reachable, as currently surfaced by many intermediate failures 3. Potential for conflicts with other system software due to "unusual" combinations of e.g. compiler and stdlibs => Standard compilers should be preferred instead of this PPA The Drone script mentioned above will no longer add the PPA by default in the near future [3], flipping the default from opt-out to opt-in. Setting `$ADD_UBUNTU_TOOLCHAIN_PPA=true` allows to *selectively* add it automatically (again) However the changed default will cause failures for Drone jobs using some combinations of compiler and OS. A short term remedy is to globally set `$ADD_UBUNTU_TOOLCHAIN_PPA=true`for the Drone workflow in the repos `.drone.star` with the disadvantages mentioned above. This is what my PRs do, as the right solution below is unfeasible to do alone for the 30 repos. The better solution is to update the CI config to only use "supported" combinations, i.e. compilers that are natively available in the OS version. This can be done by taking the .drone.star from Boost.CI [4] or, for special needs, at least use it to find supported configurations. I strongly encourage authors/maintainers to update their CI accordingly and take that opportunity to ensure all CI (still) passes. - Alex [1] https://github.com/boostorg/boost-ci/blob/master/ci/drone/linux-cxx-install… [3] https://github.com/boostorg/boost-ci/pull/252 [4] https://github.com/boostorg/boost-ci/blob/master/.drone.star

2 1

Updating Boost overview text
by Mark Cooper 05 May '26

05 May '26

Hi everyone, We're updating the overview description of Boost. Please review the following and provide any feedback. Thanks. __________ Boost is a collection of free, peer-reviewed, portable C++ source libraries maintained by an open community of world-class engineers. For more than a quarter century, Boost has set the standard for C++ library engineering. Delivering capabilities the standard does not, from high performance containers and networking to numerical computing and coroutines. Smart pointers, filesystem, regex, variant: they became part of modern C++ because Boost built them first and proved they belonged there. The world's most demanding organizations have validated this work. Aerospace, defense, high frequency trading systems, video games, large scale database engines. When the stakes are highest, Boost is in the stack. And through the Boost Software License, every line of it is freely available for commercial and open source use alike, with no obligation to release your code. Great engineering compounds. Boost is where the next generation of C++ takes shape.

5 7

Seeking Endorsement: Boost.int128
by Matt Borland 30 Apr '26

30 Apr '26

Dear All, I am seeking endorsement for review of my library int128 [1]. The library requires only C++14, is header only, and has no mandatory dependencies. What does int128 provide? Two portable and performant types: a 128-bit signed integer and a 128-bit unsigned integer, as well as a standard library for them. The performance of these types have been tuned and tested on a variety of architectures to include: x64, x32, s390x, ARM64, ARM32, PPC64LE. Both of the types and most of their library functions also work inside CUDA kernels. Benchmarks against Boost.Multiprecision, Absl, MSVC's software 128-bit integers, and built-ins, are available [2]. A couple of questions that I anticipate: Why do we need this if we already have Boost.Multiprecision? An old compliant against Boost.Multiprecision is that the 128-bit integer types are not 16 bytes [3]. The 128-bit integer types are also incident to the arbitrary precision type rather than a dedicated implementation. This allows int128 to improve performance in places that Multiprecision can't or shouldn't which is reflected in the benchmarks [2]. Should this go in Core (or other existing lib)? I talked with Peter about this a while back, but int128 was already getting too big at the time. Now int128's include/ directory has a higher sloccount than core's, so it makes even less sense. I would rather it not go into Multiprecision, as int128 would have a module weight of up to 5 (optional dependencies), whereas Multiprecision has a module weight of 25 [4]. The design is fundamentally different than the types used in Multiprecision as well (All types are backends into a master template called number for compatibility) Why does the library have a low number of stars? This library started life as the backend for Boost.Decimal since we needed a cross platform 128-bit integer for the representation of decimal128_t as well as to perform fundamental operations with decimal64_t. You can still find a int128/ folder in Decimal that will be removed if this lib is accepted (it's a vendored version of the library now). I find these types useful for my own purposes, so I expect others will too. Please let me know if you have any questions as you take a look at the library. Thanks for your time, Matt [1] https://github.com/cppalliance/int128 [2] https://develop.int128.cpp.al/u128_benchmarks.html [3] https://stackoverflow.com/questions/41876253/boostmultiprecisionuint128-t-s… [4] https://pdimov.github.io/boostdep-report/develop/module-weights.html

13 46

std::core_dump() Newsletter Moving to Quarterly
by Mark Cooper 30 Apr '26

30 Apr '26

Hey, quick update on std::core_dump(): We're moving to a quarterly publishing schedule for the foreseeable future. The team is deep in a number of other initiatives and we need to prioritize accordingly. We'll be reaching out in late June to gather suggestions and content for the July issue. Thanks!

1 0