June 2026 - Boost - lists.boost.org

Boost Review for Capy and Corosio - June 23 to July 7th
by Jeff Garland 20 Jun '26

20 Jun '26

Dear Boost Community: The Boost Formal Review of the *Corosio* and *Capy* libraries will begin on *June 23, 2026* and will conclude on *July 7, 2026*. I'm Jeff Garland and I'll be the review manager. I'd like to thank Vinnie for inviting me to maintain the continuity from Boost.Asio and I'll apologize now for the late notice. Since this is a two library review the period is somewhat extended from normal. In fact my personal pre-review indicates we will likely need an extension due to the size of the libraries -- I'll work with the review wizards on that. Capy Capy is a coroutine foundation library providing task types, execution contexts, executors, asynchronous synchronization primitives, buffer abstractions, and coroutine composition facilities. It serves as the execution and asynchronous programming substrate upon which Corosio is built. Repository: - Capy GitHub Repository <https://github.com/cppalliance/capy?utm_source=chatgpt.com> - docs <https://develop.capy.cpp.al/capy/index.html> Corosio Corosio is a coroutine-native asynchronous I/O library for C++20. It provides networking and I/O facilities designed specifically for coroutines, with awaitable operations, executor affinity, cancellation support, and cross-platform implementations based on IOCP, epoll, and kqueue. Repository: - Corosio GitHub Repository <https://github.com/cppalliance/corosio?utm_source=chatgpt.com> - docs <https://develop.corosio.cpp.al/corosio/index.html> Review Questions Potential reviewers are encouraged to consider the following questions: 1. What is your evaluation of the usefulness of the libraries? 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. Have you used either or both libraries? What was your experience? 6. Are the libraries ready for inclusion in Boost? 7. If not, what changes would you recommend before acceptance? 8. Do the libraries fit well within the existing Boost ecosystem? 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed? How to Participate Please post your review to the Boost Developers mailing list. Reviews from both experienced Boost contributors and first-time reviewers are encouraged. Reports based on real-world usage, experimentation, code inspection, and documentation review are all valuable contributions. At the conclusion of the review period, the review manager will consider all feedback and determine whether the libraries should be accepted into Boost. We look forward to your participation in this review.

4 4

Boost.Graph Documentation Got a Facelift: Ship it Or Not ?
by Arnaud Becheler 20 Jun '26

20 Jun '26

Dear Boostlings, Graphlings, We have taken a first step in modernizing the Boost.Graph documentation with a preview available here: https://491.graph.prtest3.cppalliance.org/graph/index.html . These first steps aim at solving low-hanging fruits and answering frequent complaints from users collected during the 2022 User Survey ( https://www.reddit.com/r/cpp/comments/vyt4t5/boostgraph_user_survey/ ) and BGL workshop 2026 ( https://github.com/boostorg/graph/discussions/466 ) - documentation hard to explore (no table of content, no search bar) - examples use old C++ and several don't even compile - outdated visual design We have been investing into several dimensions: - migrating the old pure html pages to asciidoc + antora - modern examples for each algorithm are compiled and run in CI, with output integrated in the documentation - higher scanability for algorithm complexity + where defined - a better landing for users not familiar with property maps The PR currently sits unmerged as we are trying to assess its viability. Important: - this is NOT the final vision, this is meant as a first important step. - the current scope is NOT a full rewrite/reorganization of each algorithm page (future work). - the current scope is a modernization of the documentation infrastructure. - we are just worried we may have made and missed important mistakes that should prevent the merge, so Jeremy Murphy (principal BGL maintainer) and I decided to poll around for general review and feeling. Question to the community: 1. Is the new documentation preview ( https://491.graph.prtest3.cppalliance.org/graph/index.html ) going in the right direction? 2. Is it better than the old documentation ( https://www.boost.org/doc/libs/1\_91\_0/libs/graph/doc/ )? 3. Would you want to see it merged in its current state or did you identify important mistakes we should absolutely fix before merge? Any general complaints not directly related to this PR scope is welcome and will be integrated in future work :) Thank you, Arno

4 10

100MB of Node.js modules shipped in the Boost release tarball
by Jonathan Wakely 19 Jun '26

19 Jun '26

There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball. Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems. Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball? I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.

5 12

[icl] Request to merge PR#54
by Joaquin M López Muñoz 15 Jun '26

15 Jun '26

Hi, In its version 22, libc++ introduced changes to their implementation of non-heterogeneous lookup for associative containers that break some assumptions Boost.ICL relies on: https://github.com/llvm/llvm-project/issues/183189 Turns out lookup for associative containers has been poorly specified since forever. I submitted an issue to the WG21 committee positing that a resolution should be adopted that (among other things) would make Boost.ICL assumptions correct: https://cplusplus.github.io/LWG/issue4572 In the latest meeting in Brno, however, the committee decided against that resolution with the result that, pending an upcoming reformulation of the affected part of the standard, Boost.ICL will be officially relying on undefined behavior. I've written a PR to circumvent this problem: https://github.com/boostorg/icl/pull/54 that relies on heterogeneous lookup (well defined and compatible with the asumptions made by Boost.ICL). I contacted the library maintainer some weeks ago but received no answer, so I'm asking here for this PR to be merged before Boost 1.92, since without it, Boost.ICL is currently broken for libc++ v22. FWIW, some users of Boost.ICL are already applying this fix to their local deployments of Boost: https://github.com/azahar-emu/ext-boost/commit/6a85c3100499e886e11c87a5c210… Another contributor has posted a different PR with the same goal: https://github.com/boostorg/icl/pull/57 My analisys is that this PR is not as comprehensive as PR#54 (it fails to cover intervals of type right_open_interval and related), plus its performance is probably slightly inferior, so I still recommend that PR#54 be used instead. Thank you, Joaquín M López Muñoz

1 0

[Patch] modernize the codebase of Boost.Format which replace the old typdef with using alias
by frex_vk9 15 Jun '26

15 Jun '26

Hello. I saw that Boost require C++11 so i modernize the codebase of Boost.Format i replaced the old typedef with using alias for upgrade the lisibility for codebase in the future. and the test with b2 passed. Read the .patch file for review my commit. Regards. frex_vk9(a)proton.me

2 1

Vcpkg Binary Caching on GitHub Finally Made Easy
by Richard 14 Jun '26

14 Jun '26

Hi Boosters, <https://github.com/LegalizeAdulthood/vcpkg-github-cache> For a long time I've struggled with vcpkg binary caching on my github CI jobs. There's a variety of critical information buried deep across various documentation pages that all interact when you attempt to use binary caching on a github repository with public github runners and CI workflows. This weekend I finally got it all figured out and debugged for my public repositories and realized that the steps needed to make everything work are non-obvious and intricate. This is the perfect thing for packaging up as a github workflow action for reuse across repositories. This project consists of two actions: - one that does all the setup - one that analyzes your build log This gives you details on how your build interacted with vcpkg binary caching to report problems. Usually the build summary is all you need to understand the cache: cold seed, warm hit, partial hit, etc. Should you need to dig in deeper to debug a weird situation there are two knobs -- debug and trace -- that can give you enough detail on everything that happened so you can sort out problems without having to manually add logging to your workflow. It may still be necessary to manually adjust the permissions on individual packages that are shared across repositories on your account. Unfortunately there's no way to manipulate the permissions programmatically. The analyze action smooths this out by giving you a table of packages that had permission issues, with links to each package's permission page on github. From there you can quickly adjust permissions as needed without having to hunt through a long list of packages on your account. -- Richard -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0