<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.8.7">Jekyll</generator><link href="http://cppalliance.org/feed.xml" rel="self" type="application/atom+xml" /><link href="http://cppalliance.org/" rel="alternate" type="text/html" /><updated>2026-04-03T11:58:14+00:00</updated><id>http://cppalliance.org/feed.xml</id><title type="html">The C++ Alliance</title><subtitle>The C++ Alliance is dedicated to helping the C++ programming language evolve. We see it developing as an ecosystem of open source libraries and as a growing community of those who contribute to those libraries..</subtitle><entry><title type="html">Hubs, intervals and math</title><link href="http://cppalliance.org/joaquin/2026/04/02/Joaquins2026Q1Update.html" rel="alternate" type="text/html" title="Hubs, intervals and math" /><published>2026-04-02T00:00:00+00:00</published><updated>2026-04-02T00:00:00+00:00</updated><id>http://cppalliance.org/joaquin/2026/04/02/Joaquins2026Q1Update</id><content type="html" xml:base="http://cppalliance.org/joaquin/2026/04/02/Joaquins2026Q1Update.html">&lt;p&gt;During Q1 2026, I’ve been working in the following areas:&lt;/p&gt;

&lt;h3 id=&quot;boostcontainerhub&quot;&gt;&lt;code&gt;boost::container::hub&lt;/code&gt;&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/joaquintides/hub&quot;&gt;&lt;code&gt;boost::container::hub&lt;/code&gt;&lt;/a&gt; is a nearly drop-in replacement of

C++26 &lt;a href=&quot;https://eel.is/c++draft/sequences#hive&quot;&gt;&lt;code&gt;std::hive&lt;/code&gt;&lt;/a&gt; sporting a simpler data structure and

providing competitive performance with respect to the de facto reference implementation

&lt;a href=&quot;https://github.com/mattreecebentley/plf_hive&quot;&gt;&lt;code&gt;plf::hive&lt;/code&gt;&lt;/a&gt;. When I first read about &lt;code&gt;std::hive&lt;/code&gt;,

I couldn’t help thinking how complex the internal design of the container is, and wondered

if something leaner could in fact be more effective. &lt;code&gt;boost::container::hub&lt;/code&gt; critically relies

on two realizations:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Identification of empty slots by way of &lt;a href=&quot;https://en.cppreference.com/w/cpp/numeric/countr_zero.html&quot;&gt;&lt;code&gt;std::countr_zero&lt;/code&gt;&lt;/a&gt;

operations on a bitmask is extremely fast.&lt;/li&gt;

&lt;li&gt;Modern allocators are very fast, too: &lt;code&gt;boost::container::hub&lt;/code&gt; does many more allocations

than &lt;code&gt;plf::hive&lt;/code&gt;, but this doesn’t degrade its performance significantly (although it affects

cache locality).&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;&lt;code&gt;boost::container::hub&lt;/code&gt; is formally proposed for inclusion in Boost.Container and will be

officially reviewed April 16-26. Ion Gaztañaga serves as the review manager.&lt;/p&gt;

&lt;h3 id=&quot;using-stdcpp-2026&quot;&gt;using std::cpp 2026&lt;/h3&gt;

&lt;p&gt;I gave my talk &lt;a href=&quot;https://github.com/joaquintides/usingstdcpp2026&quot;&gt;“The Mathematical Mind of a C++ Programmer”&lt;/a&gt;

at the &lt;a href=&quot;https://eventos.uc3m.es/141471/detail/using-std-cpp-2026.html&quot;&gt;using std::cpp 2026&lt;/a&gt; conference

taking place in Madrid during March 16-19. I had a lot of fun preparing the presentation and

delivering the actual talk, and some interesting discussions were had around it.

This is a subject I’ve been wanting to talk about for decades, so I’m somewhat relieved I finally

got it over with this year. Always happy to discuss C++ and math, so if you have feedback

or want to continue the conversation, please reach out to me.&lt;/p&gt;

&lt;h3 id=&quot;boostunordered&quot;&gt;Boost.Unordered&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Written maintenance fixes

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/328&quot;&gt;PR#328&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/335&quot;&gt;PR#335&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/336&quot;&gt;PR#336&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/337&quot;&gt;PR#337&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/339&quot;&gt;PR#339&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/344&quot;&gt;PR#344&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/345&quot;&gt;PR#345&lt;/a&gt;. Some of these fixes are related

to Node.js vulnerabilities in the Antora setup used for doc building: as the number

of Boost libraries using Antora is bound to grow, maybe we should think of an automated

way to get these vulnerabilities automatically fixed for the whole project.&lt;/li&gt;

&lt;li&gt;Reviewed and merged

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/317&quot;&gt;PR#317&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/332&quot;&gt;PR#332&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/334&quot;&gt;PR#334&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/341&quot;&gt;PR#341&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/342&quot;&gt;PR#342&lt;/a&gt;. Many thanks to

Sam Darwin, Braden Ganetsky and Andrey Semashev for their contributions.&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;boostbimap&quot;&gt;Boost.Bimap&lt;/h3&gt;

&lt;p&gt;Merged

&lt;a href=&quot;https://github.com/boostorg/bimap/pull/31&quot;&gt;PR#31&lt;/a&gt; (&lt;code&gt;std::initializer_list&lt;/code&gt;

constructor) and provided testing and documentation for this new

feature (&lt;a href=&quot;https://github.com/boostorg/bimap/pull/54&quot;&gt;PR#54&lt;/a&gt;). The original

PR was silently sitting on the queue for more than four years and it

was only when it was brought to my attention in a Reddit conversation that

I got to take a look at it. Boost.Bimap needs an active mantainer,

I guess I could become this person.&lt;/p&gt;

&lt;h3 id=&quot;boosticl&quot;&gt;Boost.ICL&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/llvm/llvm-project/pull/161366&quot;&gt;Recent changes&lt;/a&gt; in libc++ v22

code for associative container lookup have resulted in the

&lt;a href=&quot;https://github.com/boostorg/icl/issues/51&quot;&gt;breakage of Boost.ICL&lt;/a&gt;.

My understanding is that the changes in libc++ are not

standards conformant, and there’s an &lt;a href=&quot;https://github.com/llvm/llvm-project/issues/187667&quot;&gt;ongoing discussion&lt;/a&gt;

on that; in the meantime, I wrote and proposed a &lt;a href=&quot;https://github.com/boostorg/icl/pull/54&quot;&gt;PR&lt;/a&gt;

to Boost.ICL that fixes the problem (pending acceptance).&lt;/p&gt;

&lt;h3 id=&quot;support-to-the-community&quot;&gt;Support to the community&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;I’ve been helping a bit with Mark Cooper’s very successful

&lt;a href=&quot;https://x.com/search?q=%22Boost%20Blueprint%22&amp;amp;src=typed_query&amp;amp;f=live&quot;&gt;Boost Blueprint&lt;/a&gt;

series on X.&lt;/li&gt;

&lt;li&gt;Supporting the community as a member of the Fiscal Sponsorship Committee (FSC).&lt;/li&gt;

&lt;/ul&gt;</content><author><name></name></author><category term="joaquin" /><summary type="html">During Q1 2026, I’ve been working in the following areas: boost::container::hub boost::container::hub is a nearly drop-in replacement of C++26 std::hive sporting a simpler data structure and providing competitive performance with respect to the de facto reference implementation plf::hive. When I first read about std::hive, I couldn’t help thinking how complex the internal design of the container is, and wondered if something leaner could in fact be more effective. boost::container::hub critically relies on two realizations: Identification of empty slots by way of std::countr_zero operations on a bitmask is extremely fast. Modern allocators are very fast, too: boost::container::hub does many more allocations than plf::hive, but this doesn’t degrade its performance significantly (although it affects cache locality). boost::container::hub is formally proposed for inclusion in Boost.Container and will be officially reviewed April 16-26. Ion Gaztañaga serves as the review manager. using std::cpp 2026 I gave my talk “The Mathematical Mind of a C++ Programmer” at the using std::cpp 2026 conference taking place in Madrid during March 16-19. I had a lot of fun preparing the presentation and delivering the actual talk, and some interesting discussions were had around it. This is a subject I’ve been wanting to talk about for decades, so I’m somewhat relieved I finally got it over with this year. Always happy to discuss C++ and math, so if you have feedback or want to continue the conversation, please reach out to me. Boost.Unordered Written maintenance fixes PR#328, PR#335, PR#336, PR#337, PR#339, PR#344, PR#345. Some of these fixes are related to Node.js vulnerabilities in the Antora setup used for doc building: as the number of Boost libraries using Antora is bound to grow, maybe we should think of an automated way to get these vulnerabilities automatically fixed for the whole project. Reviewed and merged PR#317, PR#332, PR#334, PR#341, PR#342. Many thanks to Sam Darwin, Braden Ganetsky and Andrey Semashev for their contributions. Boost.Bimap Merged PR#31 (std::initializer_list constructor) and provided testing and documentation for this new feature (PR#54). The original PR was silently sitting on the queue for more than four years and it was only when it was brought to my attention in a Reddit conversation that I got to take a look at it. Boost.Bimap needs an active mantainer, I guess I could become this person. Boost.ICL Recent changes in libc++ v22 code for associative container lookup have resulted in the breakage of Boost.ICL. My understanding is that the changes in libc++ are not standards conformant, and there’s an ongoing discussion on that; in the meantime, I wrote and proposed a PR to Boost.ICL that fixes the problem (pending acceptance). Support to the community I’ve been helping a bit with Mark Cooper’s very successful Boost Blueprint series on X. Supporting the community as a member of the Fiscal Sponsorship Committee (FSC).</summary></entry><entry><title type="html">Systems, CI Updates Q1 2026</title><link href="http://cppalliance.org/sam/2026/03/31/SamsQ1Update.html" rel="alternate" type="text/html" title="Systems, CI Updates Q1 2026" /><published>2026-03-31T00:00:00+00:00</published><updated>2026-03-31T00:00:00+00:00</updated><id>http://cppalliance.org/sam/2026/03/31/SamsQ1Update</id><content type="html" xml:base="http://cppalliance.org/sam/2026/03/31/SamsQ1Update.html">&lt;h3 id=&quot;code-coverage-reports---designing-new-gcovr-templates&quot;&gt;Code Coverage Reports - designing new GCOVR templates&lt;/h3&gt;

&lt;p&gt;A major effort this quarter and continuing on since it was mentioned in the last newsletter is the development of codecov-like coverage reports that run in GitHub Actions and are hosted on GitHub Pages. Instructions: &lt;a href=&quot;https://github.com/boostorg/boost-ci/blob/master/docs/code-coverage.md&quot;&gt;Code Coverage with Github Actions and Github Pages&lt;/a&gt;. The process has really highlighted a phenomenon in open-source software where by publishing something to the whole community, end-users respond back with their own suggestions and fixes, and everything improves iteratively. It would not have happened otherwise. The upstream GCOVR project has taken an interest in the templates and we are working on merging them into the main repository for all gcovr users. Boost contributors and gcovr maintainers have suggested numerous modifications for the templates. Great work by Julio Estrada on the template development.&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Better full page scrolling of C++ source code files&lt;/li&gt;

&lt;li&gt;Include ‘functions’ listings on every page&lt;/li&gt;

&lt;li&gt;Optionally disable branch coverage&lt;/li&gt;

&lt;li&gt;Purposely restrict coverage directories to src/ and include/&lt;/li&gt;

&lt;li&gt;Another scrolling bug fixed&lt;/li&gt;

&lt;li&gt;Both blue and green colored themes&lt;/li&gt;

&lt;li&gt;Codacy linting&lt;/li&gt;

&lt;li&gt;New forward and back buttons. Allows navigation to each “miss” and subsequent pages&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;server-hosting&quot;&gt;Server Hosting&lt;/h3&gt;

&lt;p&gt;This quarter we decommissioned the Rackspace servers which had been in service 10-15 years. Rene provided a nice announcement:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://lists.boost.org/archives/list/boost@lists.boost.org/thread/XYFD42TTQRYHWTLGP6GCIZQ6NHCZLNQT/&quot;&gt;Farewell to Wowbagger - End of an Era for boost.org&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;There was more to do then just delete servers, I built a new results.boost.org FTP server replacing the preexisting FTP server used by regression.boost.org. Configured and tested it. Inventoried the old machines, including a monitoring server. Built a replacement wowbagger called wowbagger2 to host a copy of the website - original.boost.org. The monthly cost of a small GCP Compute instance seems to be around 5% of the Rackspace legacy cloud server. Components: Ubuntu 24.04. Apache. PHP 5 PPA. “original.boost.org” continues to host a copy of the earlier boost.org website for comparison and development purposes which is interesting to check.&lt;/p&gt;

&lt;p&gt;Launched server instances for corosio.org and paperflow.&lt;/p&gt;

&lt;h3 id=&quot;fil-c&quot;&gt;Fil-C&lt;/h3&gt;

&lt;p&gt;Working with Tom Kent to add Fil-C https://github.com/pizlonator/fil-c test into the regression matrix https://regression.boost.org/ .

Built a Fil-C container image based on Drone images.

Debugging the build process. After a few roadblocks, the latest news is that Fil-C seems to be successfully building. This is not quite finished but should be online soon.&lt;/p&gt;

&lt;h3 id=&quot;boost-release-process-boostorgrelease-tools&quot;&gt;Boost release process boostorg/release-tools&lt;/h3&gt;

&lt;p&gt;The boostorg/boost CircleCI jobs often threaten to cross the 1-hour time limit. Increased parallel processes from 4 to 8. Increased instance size from medium to large.

And yet another adjustment: there are 4 compression algorithms used by the releases (gz, bz2, 7z, zip) and it is possible to find drop-in replacement programs that

go much faster than the standard ones by utilizing parallelization. lbzip2 pigz. The substitute binaries were applied to publish-releases.py recently. Now the same idea in ci_boost_release.py. All of this reduced the CircleCI job time by many minutes.&lt;/p&gt;

&lt;p&gt;Certain boost library pull requests were finally merged after a long delay allowing an upgrade of the Sphinx pip package. Tested a superproject container image for the CircleCI jobs with updated pip packages. Boost is currently in a code freeze so this will not go live until after 1.91.0. Sphinx docs continue to deal with upgrade incompatibilities. I prepared another set of pull requests to send to boost libraries using Sphinx.&lt;/p&gt;

&lt;h3 id=&quot;doc-previews-and-doc-builds&quot;&gt;Doc Previews and Doc Builds&lt;/h3&gt;

&lt;p&gt;Antora docs usually show an “Edit this Page” link. Recently a couple of Alliance developers happened to comment the link didn’t quite work in some of the doc previews, and so that opened a topic to research solutions and make the Antora edit-this-page feature more robust if possible. The issue is that Boost libraries are git submodules. When working as expected submodules are checked out as “HEAD detached at a74967f0” rather than “develop”. If Antora’s edit-this-page code sees “HEAD detached at a74967f0” it will default to the path HEAD. That’s wrong on the GitHub side. A solution we found (credit to Ruben Perez) is to set the antora config to edit_url: ‘{web_url}/edit/develop/{path}’. Don’t leave a {ref} type of variable in the path.&lt;/p&gt;

&lt;p&gt;Rolling out the antora-downloads-extension to numerous boost and alliance repositories. It will retry the ui-bundle download.&lt;/p&gt;

&lt;p&gt;Refactored the release-tools build_docs scripts so that the gems and pip packages are organized into a format that matches Gemfile and requirement.txt files, instead of what the script was doing before “gem install package”. By using a Gemfile, the script becomes compatible with other build systems so content can be copy-pasted easily.&lt;/p&gt;

&lt;p&gt;CircleCI superproject builds use docbook-xml.zip, where the download url broke. Switched the link address. Also hosting a copy of the file at https://dl.cpp.al/misc/docbook-xml.zip&lt;/p&gt;

&lt;h3 id=&quot;boost-website-boostorgwebsite-v2&quot;&gt;Boost website boostorg/website-v2&lt;/h3&gt;

&lt;p&gt;Collaborated in the process of on-boarding the consulting company Metalab who are working on V3, the next iteration of the boost.org website.&lt;/p&gt;

&lt;p&gt;Disable Fastly caching to assist metalab developers.&lt;/p&gt;

&lt;p&gt;Gitflow workflow planning meetings.&lt;/p&gt;

&lt;p&gt;Discussions about how Tools should be present on the libraries pages.&lt;/p&gt;

&lt;p&gt;On the DB servers, adjusted postgresql authentication configurations from md5 to scram-sha-256 on all databases and multiple ansible roles. Actually this turns out to be a superficial change even though it should be done. The reason is that newer postgres will use scram-sha-256 behind-the-scenes regardless.&lt;/p&gt;

&lt;p&gt;Wrote deploy-qa.sh, a script to enable metalab QA engineers to deploy a pull request onto a test server. The precise git SHA commit of any open pull request can be tested.&lt;/p&gt;

&lt;p&gt;Wrote upload-images.sh, a script to store Bob Ostrom’s boost cartoons in S3 instead of the github repo.&lt;/p&gt;

&lt;h3 id=&quot;mailman3&quot;&gt;Mailman3&lt;/h3&gt;

&lt;p&gt;Synced production lists to the staging server. Wrote a document in the cppalliance/boost-mailman repo explaining how the multi-step process of syncing can be done.&lt;/p&gt;

&lt;h3 id=&quot;boostorg&quot;&gt;boostorg&lt;/h3&gt;

&lt;p&gt;Migrated cppalliance/decimal to boostorg/decimal.&lt;/p&gt;

&lt;h3 id=&quot;jenkins&quot;&gt;Jenkins&lt;/h3&gt;

&lt;p&gt;The Jenkins server is building documentation previews for dozens of boostorg and cppalliance repositories where each job is assigned its own “workspace” directory and then proceeds to install 1GB of node_modules. That was happening for every build and every pull request. The disk space on the server was filling up, every few weeks yet another 100GB. Rather than continue to resize the disk, or delete all jobs too quickly, was there the opportunity for optimization? Yes. In the superproject container image relocate the nodejs installation to /opt/nvm instead of root’s home directory. The /opt/nvm installation can now be “shared” by other jobs which reduces space. Conditionally check if mermaid is needed and/or if mermaid is already available in /opt/nvm. With these modifications, since each job doesn’t need to install a large amount of npm packages the job size is drastically reduced.&lt;/p&gt;

&lt;p&gt;Upgraded server and all plugins. Necessary to fix spurious bugs in certain Jenkins jobs.&lt;/p&gt;

&lt;p&gt;Debugging Jenkins runners, set subnet and zone on the cloud server configurations.&lt;/p&gt;

&lt;p&gt;Fixed lcov jobs, that need cxxstd=20&lt;/p&gt;

&lt;p&gt;Migrated many administrative scripts from a local directory on the server to the jenkins-ci repository. Revise, clean, discard certain scripts.&lt;/p&gt;

&lt;p&gt;Dmitry contributed diff-reports that should now appear in every pull request which has been configured for LCOV previews.&lt;/p&gt;

&lt;p&gt;Implemented –flags in lcov build scripts [–skip-gcovr] [–skip-genhtml] [–skip-diff-report] [–only-gcovr]&lt;/p&gt;

&lt;p&gt;Ansible role task: install check_jenkins_queue nagios plugin automatically from Ansible.&lt;/p&gt;

&lt;h3 id=&quot;gha&quot;&gt;GHA&lt;/h3&gt;

&lt;p&gt;Completed a major upgrade of the Terraform installation which had lagged upstream code by nearly two years.&lt;/p&gt;

&lt;p&gt;Deployed a series of GitHub Actions runners for Joaquin’s latest benchmarks at https://github.com/boostorg/boost_hub_benchmarks. Installed latest VS2026. MacOS upgrade to 26.3.&lt;/p&gt;

&lt;h3 id=&quot;drone&quot;&gt;Drone&lt;/h3&gt;

&lt;p&gt;Launched new MacOS 26 drone runners, and FreeBSD 15.0 drone runners.&lt;/p&gt;</content><author><name></name></author><category term="sam" /><summary type="html">Code Coverage Reports - designing new GCOVR templates A major effort this quarter and continuing on since it was mentioned in the last newsletter is the development of codecov-like coverage reports that run in GitHub Actions and are hosted on GitHub Pages. Instructions: Code Coverage with Github Actions and Github Pages. The process has really highlighted a phenomenon in open-source software where by publishing something to the whole community, end-users respond back with their own suggestions and fixes, and everything improves iteratively. It would not have happened otherwise. The upstream GCOVR project has taken an interest in the templates and we are working on merging them into the main repository for all gcovr users. Boost contributors and gcovr maintainers have suggested numerous modifications for the templates. Great work by Julio Estrada on the template development. Better full page scrolling of C++ source code files Include ‘functions’ listings on every page Optionally disable branch coverage Purposely restrict coverage directories to src/ and include/ Another scrolling bug fixed Both blue and green colored themes Codacy linting New forward and back buttons. Allows navigation to each “miss” and subsequent pages Server Hosting This quarter we decommissioned the Rackspace servers which had been in service 10-15 years. Rene provided a nice announcement: Farewell to Wowbagger - End of an Era for boost.org There was more to do then just delete servers, I built a new results.boost.org FTP server replacing the preexisting FTP server used by regression.boost.org. Configured and tested it. Inventoried the old machines, including a monitoring server. Built a replacement wowbagger called wowbagger2 to host a copy of the website - original.boost.org. The monthly cost of a small GCP Compute instance seems to be around 5% of the Rackspace legacy cloud server. Components: Ubuntu 24.04. Apache. PHP 5 PPA. “original.boost.org” continues to host a copy of the earlier boost.org website for comparison and development purposes which is interesting to check. Launched server instances for corosio.org and paperflow. Fil-C Working with Tom Kent to add Fil-C https://github.com/pizlonator/fil-c test into the regression matrix https://regression.boost.org/ . Built a Fil-C container image based on Drone images. Debugging the build process. After a few roadblocks, the latest news is that Fil-C seems to be successfully building. This is not quite finished but should be online soon. Boost release process boostorg/release-tools The boostorg/boost CircleCI jobs often threaten to cross the 1-hour time limit. Increased parallel processes from 4 to 8. Increased instance size from medium to large. And yet another adjustment: there are 4 compression algorithms used by the releases (gz, bz2, 7z, zip) and it is possible to find drop-in replacement programs that go much faster than the standard ones by utilizing parallelization. lbzip2 pigz. The substitute binaries were applied to publish-releases.py recently. Now the same idea in ci_boost_release.py. All of this reduced the CircleCI job time by many minutes. Certain boost library pull requests were finally merged after a long delay allowing an upgrade of the Sphinx pip package. Tested a superproject container image for the CircleCI jobs with updated pip packages. Boost is currently in a code freeze so this will not go live until after 1.91.0. Sphinx docs continue to deal with upgrade incompatibilities. I prepared another set of pull requests to send to boost libraries using Sphinx. Doc Previews and Doc Builds Antora docs usually show an “Edit this Page” link. Recently a couple of Alliance developers happened to comment the link didn’t quite work in some of the doc previews, and so that opened a topic to research solutions and make the Antora edit-this-page feature more robust if possible. The issue is that Boost libraries are git submodules. When working as expected submodules are checked out as “HEAD detached at a74967f0” rather than “develop”. If Antora’s edit-this-page code sees “HEAD detached at a74967f0” it will default to the path HEAD. That’s wrong on the GitHub side. A solution we found (credit to Ruben Perez) is to set the antora config to edit_url: ‘{web_url}/edit/develop/{path}’. Don’t leave a {ref} type of variable in the path. Rolling out the antora-downloads-extension to numerous boost and alliance repositories. It will retry the ui-bundle download. Refactored the release-tools build_docs scripts so that the gems and pip packages are organized into a format that matches Gemfile and requirement.txt files, instead of what the script was doing before “gem install package”. By using a Gemfile, the script becomes compatible with other build systems so content can be copy-pasted easily. CircleCI superproject builds use docbook-xml.zip, where the download url broke. Switched the link address. Also hosting a copy of the file at https://dl.cpp.al/misc/docbook-xml.zip Boost website boostorg/website-v2 Collaborated in the process of on-boarding the consulting company Metalab who are working on V3, the next iteration of the boost.org website. Disable Fastly caching to assist metalab developers. Gitflow workflow planning meetings. Discussions about how Tools should be present on the libraries pages. On the DB servers, adjusted postgresql authentication configurations from md5 to scram-sha-256 on all databases and multiple ansible roles. Actually this turns out to be a superficial change even though it should be done. The reason is that newer postgres will use scram-sha-256 behind-the-scenes regardless. Wrote deploy-qa.sh, a script to enable metalab QA engineers to deploy a pull request onto a test server. The precise git SHA commit of any open pull request can be tested. Wrote upload-images.sh, a script to store Bob Ostrom’s boost cartoons in S3 instead of the github repo. Mailman3 Synced production lists to the staging server. Wrote a document in the cppalliance/boost-mailman repo explaining how the multi-step process of syncing can be done. boostorg Migrated cppalliance/decimal to boostorg/decimal. Jenkins The Jenkins server is building documentation previews for dozens of boostorg and cppalliance repositories where each job is assigned its own “workspace” directory and then proceeds to install 1GB of node_modules. That was happening for every build and every pull request. The disk space on the server was filling up, every few weeks yet another 100GB. Rather than continue to resize the disk, or delete all jobs too quickly, was there the opportunity for optimization? Yes. In the superproject container image relocate the nodejs installation to /opt/nvm instead of root’s home directory. The /opt/nvm installation can now be “shared” by other jobs which reduces space. Conditionally check if mermaid is needed and/or if mermaid is already available in /opt/nvm. With these modifications, since each job doesn’t need to install a large amount of npm packages the job size is drastically reduced. Upgraded server and all plugins. Necessary to fix spurious bugs in certain Jenkins jobs. Debugging Jenkins runners, set subnet and zone on the cloud server configurations. Fixed lcov jobs, that need cxxstd=20 Migrated many administrative scripts from a local directory on the server to the jenkins-ci repository. Revise, clean, discard certain scripts. Dmitry contributed diff-reports that should now appear in every pull request which has been configured for LCOV previews. Implemented –flags in lcov build scripts [–skip-gcovr] [–skip-genhtml] [–skip-diff-report] [–only-gcovr] Ansible role task: install check_jenkins_queue nagios plugin automatically from Ansible. GHA Completed a major upgrade of the Terraform installation which had lagged upstream code by nearly two years. Deployed a series of GitHub Actions runners for Joaquin’s latest benchmarks at https://github.com/boostorg/boost_hub_benchmarks. Installed latest VS2026. MacOS upgrade to 26.3. Drone Launched new MacOS 26 drone runners, and FreeBSD 15.0 drone runners.</summary></entry><entry><title type="html">Statement from the C++ Alliance on WG21 Committee Meeting Support</title><link href="http://cppalliance.org/company/2026/03/27/WG21-Meeting-Support-Statement.html" rel="alternate" type="text/html" title="Statement from the C++ Alliance on WG21 Committee Meeting Support" /><published>2026-03-27T00:00:00+00:00</published><updated>2026-03-27T00:00:00+00:00</updated><id>http://cppalliance.org/company/2026/03/27/WG21-Meeting-Support-Statement</id><content type="html" xml:base="http://cppalliance.org/company/2026/03/27/WG21-Meeting-Support-Statement.html">&lt;p&gt;The C++ Alliance is proud to support attendance at WG21 committee meetings. We believe that facilitating the attendance of domain experts produces better outcomes for C++ and for the broader ecosystem, and we are committed to making participation more accessible.&lt;/p&gt;

&lt;p&gt;We want to be unequivocally clear: the C++ Alliance does not, and will never, direct or compel attendees to vote in any particular way. Our support comes with no strings attached. Those who attend are free and encouraged to exercise their independent judgment on every proposal before the committee.&lt;/p&gt;

&lt;p&gt;The integrity of the WG21 standards process depends on the independence of its participants. We respect that process deeply, and any suggestion to the contrary does not reflect our values or our program.&lt;/p&gt;

&lt;p&gt;If you are interested in learning more about our attendance program, please reach out to us at &lt;a href=&quot;mailto:info@cppalliance.org&quot;&gt;info@cppalliance.org&lt;/a&gt;.&lt;/p&gt;</content><author><name></name></author><category term="company" /><summary type="html">The C++ Alliance is proud to support attendance at WG21 committee meetings. We believe that facilitating the attendance of domain experts produces better outcomes for C++ and for the broader ecosystem, and we are committed to making participation more accessible. We want to be unequivocally clear: the C++ Alliance does not, and will never, direct or compel attendees to vote in any particular way. Our support comes with no strings attached. Those who attend are free and encouraged to exercise their independent judgment on every proposal before the committee. The integrity of the WG21 standards process depends on the independence of its participants. We respect that process deeply, and any suggestion to the contrary does not reflect our values or our program. If you are interested in learning more about our attendance program, please reach out to us at info@cppalliance.org.</summary></entry><entry><title type="html">Corosio Beta: Coroutine-Native Networking for C++20</title><link href="http://cppalliance.org/mark/2026/03/11/Corosio-Beta-Coroutine-Native-Networking.html" rel="alternate" type="text/html" title="Corosio Beta: Coroutine-Native Networking for C++20" /><published>2026-03-11T00:00:00+00:00</published><updated>2026-03-11T00:00:00+00:00</updated><id>http://cppalliance.org/mark/2026/03/11/Corosio-Beta-Coroutine-Native-Networking</id><content type="html" xml:base="http://cppalliance.org/mark/2026/03/11/Corosio-Beta-Coroutine-Native-Networking.html">&lt;h1 id=&quot;corosio-beta-coroutine-native-networking-for-c20&quot;&gt;Corosio Beta: Coroutine-Native Networking for C++20&lt;/h1&gt;

&lt;p&gt;&lt;em&gt;The C++ Alliance is releasing the Corosio beta, a networking library designed from the ground up for C++20 coroutines. We are inviting serious C++ developers to use it, break it, and tell us what needs to change before it goes to Boost formal review.&lt;/em&gt;&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;the-gap-c20-left-open&quot;&gt;The Gap C++20 Left Open&lt;/h2&gt;

&lt;p&gt;C++20 gave us coroutines. It did not give us networking to go with them. Boost.Asio has added coroutine support over the years, but its foundations were laid for a world of callbacks and completion handlers. Retrofitting coroutines onto that model produces code that works, but never quite feels like the language you are writing in. We decided to find out what networking looks like when you start over.&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;what-corosio-is&quot;&gt;What Corosio Is&lt;/h2&gt;

&lt;p&gt;Corosio is a coroutine-only networking library for C++20. It provides TCP sockets, acceptors, TLS streams, timers, and DNS resolution. Every operation is an awaitable. You write &lt;code&gt;co_await&lt;/code&gt; and the library handles executor affinity, cancellation, and frame allocation. No callbacks. No futures. No sender/receiver.&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-c&quot;&gt;auto [socket] = co_await acceptor.async_accept();

auto n = co_await socket.async_read_some(buffer);

co_await socket.async_write(response);

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Corosio runs on Windows (IOCP), Linux (epoll), and macOS (kqueue). It targets GCC 12+, Clang 17+, and MSVC 14.34+, with no dependencies outside the standard library. Capy, its I/O foundation, is fetched automatically by CMake.&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;built-on-capy&quot;&gt;Built on Capy&lt;/h2&gt;

&lt;p&gt;Corosio is built on Capy, a coroutine I/O foundation library that ships alongside it. The core insight driving Capy’s design comes from Peter Dimov: &lt;em&gt;an API designed from the ground up to use C++20 coroutines can achieve performance and ergonomics which cannot otherwise be obtained.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Capy’s &lt;em&gt;IoAwaitable&lt;/em&gt; protocol ensures coroutines resume on the correct executor after I/O completes, without thread-local globals, implicit context, or manual dispatch. Cancellation follows the same forward-propagation model: stop tokens flow from the top of a coroutine chain to the platform API boundary, giving you uniform cancellation across all operations. Frame allocation uses thread-local recycling pools to achieve zero steady-state heap allocations after warmup.&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;what-we-are-asking-for&quot;&gt;What We Are Asking For&lt;/h2&gt;

&lt;p&gt;We are looking for feedback on correctness, ergonomics, platform behavior, documentation, and performance under real workloads. Specifically:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Does the executor affinity model hold up under production conditions?&lt;/li&gt;

&lt;li&gt;Does cancellation behave correctly across complex coroutine chains?&lt;/li&gt;

&lt;li&gt;Are there platform-specific edge cases in the IOCP, epoll, or kqueue backends?&lt;/li&gt;

&lt;li&gt;Does the zero-allocation model hold in your deployment scenarios?&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;We are inviting serious C++ developers, especially if you have shipped networking code, to use it, break it, and tell us what your experience was. The Boost review process rewards libraries that arrive having already faced serious scrutiny.&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;get-it&quot;&gt;Get It&lt;/h2&gt;

&lt;pre&gt;&lt;code class=&quot;language-shell&quot;&gt;git clone https://github.com/cppalliance/corosio.git

cd corosio

cmake -S . -B build -G Ninja

cmake --build build

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Or with CMake FetchContent:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;include(FetchContent)

FetchContent_Declare(corosio

GIT_REPOSITORY https://github.com/cppalliance/corosio.git

GIT_TAG develop

GIT_SHALLOW TRUE)

FetchContent_MakeAvailable(corosio)

target_link_libraries(my_app Boost::corosio)

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;&lt;strong&gt;Requires:&lt;/strong&gt; CMake 3.25+, GCC 12+ / Clang 17+ / MSVC 14.34+&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;resources&quot;&gt;Resources&lt;/h2&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/cppalliance/corosio&quot;&gt;Corosio on GitHub&lt;/a&gt; – https://github.com/cppalliance/corosio&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://master.corosio.cpp.al/&quot;&gt;Corosio Docs&lt;/a&gt; – https://develop.corosio.cpp.al/&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/cppalliance/capy&quot;&gt;Capy on GitHub&lt;/a&gt; – https://github.com/cppalliance/capy&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://master.capy.cpp.al/&quot;&gt;Capy Docs&lt;/a&gt; – https://develop.capy.cpp.al/&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/cppalliance/corosio/issues&quot;&gt;File an Issue&lt;/a&gt; – https://github.com/cppalliance/corosio/issues&lt;/p&gt;</content><author><name></name></author><category term="mark" /><summary type="html">Corosio Beta: Coroutine-Native Networking for C++20 The C++ Alliance is releasing the Corosio beta, a networking library designed from the ground up for C++20 coroutines. We are inviting serious C++ developers to use it, break it, and tell us what needs to change before it goes to Boost formal review. The Gap C++20 Left Open C++20 gave us coroutines. It did not give us networking to go with them. Boost.Asio has added coroutine support over the years, but its foundations were laid for a world of callbacks and completion handlers. Retrofitting coroutines onto that model produces code that works, but never quite feels like the language you are writing in. We decided to find out what networking looks like when you start over. What Corosio Is Corosio is a coroutine-only networking library for C++20. It provides TCP sockets, acceptors, TLS streams, timers, and DNS resolution. Every operation is an awaitable. You write co_await and the library handles executor affinity, cancellation, and frame allocation. No callbacks. No futures. No sender/receiver. auto [socket] = co_await acceptor.async_accept(); auto n = co_await socket.async_read_some(buffer); co_await socket.async_write(response); Corosio runs on Windows (IOCP), Linux (epoll), and macOS (kqueue). It targets GCC 12+, Clang 17+, and MSVC 14.34+, with no dependencies outside the standard library. Capy, its I/O foundation, is fetched automatically by CMake. Built on Capy Corosio is built on Capy, a coroutine I/O foundation library that ships alongside it. The core insight driving Capy’s design comes 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’s IoAwaitable protocol ensures coroutines resume on the correct executor after I/O completes, without thread-local globals, implicit context, or manual dispatch. Cancellation follows the same forward-propagation model: stop tokens flow from the top of a coroutine chain to the platform API boundary, giving you uniform cancellation across all operations. Frame allocation uses thread-local recycling pools to achieve zero steady-state heap allocations after warmup. What We Are Asking For We are looking for feedback on correctness, ergonomics, platform behavior, documentation, and performance under real workloads. Specifically: Does the executor affinity model hold up under production conditions? Does cancellation behave correctly across complex coroutine chains? Are there platform-specific edge cases in the IOCP, epoll, or kqueue backends? Does the zero-allocation model hold in your deployment scenarios? We are inviting serious C++ developers, especially if you have shipped networking code, to use it, break it, and tell us what your experience was. The Boost review process rewards libraries that arrive having already faced serious scrutiny. Get It git clone https://github.com/cppalliance/corosio.git cd corosio cmake -S . -B build -G Ninja cmake --build build Or with CMake FetchContent: include(FetchContent) FetchContent_Declare(corosio GIT_REPOSITORY https://github.com/cppalliance/corosio.git GIT_TAG develop GIT_SHALLOW TRUE) FetchContent_MakeAvailable(corosio) target_link_libraries(my_app Boost::corosio) Requires: CMake 3.25+, GCC 12+ / Clang 17+ / MSVC 14.34+ Resources Corosio on GitHub – https://github.com/cppalliance/corosio Corosio Docs – https://develop.corosio.cpp.al/ Capy on GitHub – https://github.com/cppalliance/capy Capy Docs – https://develop.capy.cpp.al/ File an Issue – https://github.com/cppalliance/corosio/issues</summary></entry><entry><title type="html">A postgres library for Boost</title><link href="http://cppalliance.org/ruben/2026/01/23/Ruben2025Q4Update.html" rel="alternate" type="text/html" title="A postgres library for Boost" /><published>2026-01-23T00:00:00+00:00</published><updated>2026-01-23T00:00:00+00:00</updated><id>http://cppalliance.org/ruben/2026/01/23/Ruben2025Q4Update</id><content type="html" xml:base="http://cppalliance.org/ruben/2026/01/23/Ruben2025Q4Update.html">&lt;p&gt;Do you know Boost.MySQL? If you’ve been reading my posts, you probably do.

Many people have wondered ‘why not Postgres?’. Well, the time is now.

TL;DR: I’m writing the equivalent of Boost.MySQL, but for PostgreSQL.

You can find the code &lt;a href=&quot;https://github.com/anarthal/nativepg&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Since libPQ is already a good library, the NativePG project intends

to be more ambitious than Boost.MySQL. In addition to the expected

Asio interface, I intend to provide a sans-io API that exposes primitives

like message serialization.&lt;/p&gt;

&lt;p&gt;Throughout this post, I will go into the intended library design and the rationales

behind its design.&lt;/p&gt;

&lt;h2 id=&quot;the-lowest-level-message-serialization&quot;&gt;The lowest level: message serialization&lt;/h2&gt;

&lt;p&gt;PostgreSQL clients communicate with the server using

a binary protocol on top of TCP, termed &lt;a href=&quot;https://www.postgresql.org/docs/current/protocol.html&quot;&gt;the frontend/backend protocol&lt;/a&gt;.

The protocol defines a set of messages used for interactions. For example, when running a query, the following happens:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;┌────────┐ ┌────────┐

│ Client │ │ Server │

└───┬────┘ └───┬────┘

│ │

│ Query │

│ ──────────────────────────────────────────&amp;gt; │

│ │

│ RowDescription │

│ &amp;lt;────────────────────────────────────────── │

│ │

│ DataRow │

│ &amp;lt;────────────────────────────────────────── │

│ │

│ CommandComplete │

│ &amp;lt;────────────────────────────────────────── │

│ │

│ ReadyForQuery │

│ &amp;lt;────────────────────────────────────────── │

│ │

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;In the lowest layer, this library provides functions to serialize and parse

such messages. The goal here is being as efficient as possible.

Parsing functions are non-allocating, and use an approach inspired by

Boost.Url collections:&lt;/p&gt;

&lt;h2 id=&quot;parsing-database-types&quot;&gt;Parsing database types&lt;/h2&gt;

&lt;p&gt;The PostgreSQL type system is quite rich. In addition to the usual SQL built-in types,

it supports advanced scalars like UUIDs, arrays and user-defined aggregates.&lt;/p&gt;

&lt;p&gt;When running a query, libPQ exposes retrieved data as either raw text or bytes.

This is what the server sends in the &lt;code&gt;DataRow&lt;/code&gt; packets shown above.

To do something useful with the data, users likely need parsing and serializing

such types.&lt;/p&gt;

&lt;p&gt;The next layer of NativePG is in charge of providing such functions.

This will likely contain some extension points for users to plug in their types.

This is the general form of such functions:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;system::error_code parse(span&amp;lt;const std::byte&amp;gt; from, T&amp;amp; to, const connection_state&amp;amp;);

void serialize(const T&amp;amp; from, dynamic_buffer&amp;amp; to, const connection_state&amp;amp;);

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Note that some types might require access to session configuration.

For instance, dates may be expressed using different wire formats depending

on the connection’s runtime settings.&lt;/p&gt;

&lt;p&gt;At the time of writing, only ints and strings are supported,

but this will be extended soon.&lt;/p&gt;

&lt;h2 id=&quot;composing-requests&quot;&gt;Composing requests&lt;/h2&gt;

&lt;p&gt;Efficiency in database communication is achieved with pipelining.

A network round-trip with the server is worth a thousand allocations in the client.

It is thus critical that:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;The protocol properly supports pipelining. This is the case with PostgreSQL.&lt;/li&gt;

&lt;li&gt;The client should expose an interface to it, and make it very easy to use.

libPQ does the first, and NativePG intends to achieve the second.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;NativePG pipelines by default. In NativePG, a &lt;code&gt;request&lt;/code&gt; object is always

a pipeline:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;// Create a request

request req;

// These two queries will be executed as part of a pipeline

req.add_query(&quot;SELECT * FROM libs WHERE author = $1&quot;, {&quot;Ruben&quot;});

req.add_query(&quot;DELETE FROM libs WHERE author &amp;lt;&amp;gt; $1&quot;, {&quot;Ruben&quot;});

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Everything you may ask the server can be added to &lt;code&gt;request&lt;/code&gt;.

This includes preparing and executing statements, establishing

pipeline synchronization points, and so on.

It aims to be close enough to the protocol to be powerful,

while also exposing high-level functions to make things easier.&lt;/p&gt;

&lt;h2 id=&quot;reading-responses&quot;&gt;Reading responses&lt;/h2&gt;

&lt;p&gt;Like &lt;code&gt;request&lt;/code&gt;, the core response mechanism aims to be as close

to the protocol as possible. Since use cases here are much more varied,

there is no single &lt;code&gt;response&lt;/code&gt; class, but a concept, instead.

This is what a &lt;code&gt;response_handler&lt;/code&gt; looks like:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;

struct my_handler {

// Check that the handler is compatible with the request,

// and prepare any required data structures. Called once at the beginning

handler_setup_result setup(const request&amp;amp; req, std::size_t pipeline_offset);

// Called once for every message received from the server

// (e.g. `RowDescription`, `DataRow`, `CommandComplete`)

void on_message(const any_request_message&amp;amp; msg);

// The overall result of the operation (error_code + diagnostic string).

// Called after the operation has finished.

const extended_error&amp;amp; result() const;

};

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Note that &lt;code&gt;on_message&lt;/code&gt; is not allowed to report errors.

Even if a handler encounters a problem with a message

(imagine finding a &lt;code&gt;NULL&lt;/code&gt; for a field where the user isn’t expecting one),

this is a user error, rather than a protocol error.

Subsequent steps in the pipeline must not be affected by this.&lt;/p&gt;

&lt;p&gt;This is powerful but very low-level. Using this mechanism, the library

exposes an interface to parse the result of a query into a user-supplied

struct, using Boost.Describe:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;struct library

{

std::int32_t id;

std::string name;

std::string cpp_version;

};

BOOST_DESCRIBE_STRUCT(library, (), (id, name, cpp_version))

// ...

std::vector&amp;lt;library&amp;gt; libs;

auto handler = nativepg::into(libs); // this is a valid response_handler

&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&quot;network-algorithms&quot;&gt;Network algorithms&lt;/h2&gt;

&lt;p&gt;Given a user request and response handler, how do we send these to the server?

We need a set of network algorithms to achieve this. Some of these are trivial:

sending a request to the server is an &lt;code&gt;asio::write&lt;/code&gt; on the request’s buffer.

Others, however, are more involved:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Reading a pipeline response needs to verify that the message

sequence is what we expected, for security, and handle errors gracefully.&lt;/li&gt;

&lt;li&gt;The handshake algorithm, in charge of authentication when we connect to the

server, needs to respond to server authentication challenges, which may

come in different forms.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;Writing these using &lt;code&gt;asio::async_compose&lt;/code&gt; is problematic because:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;They become tied to Boost.Asio.&lt;/li&gt;

&lt;li&gt;They are difficult to test.&lt;/li&gt;

&lt;li&gt;They result in long compile times and code bloat due to templating.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;At the moment, these are written as finite state machines, similar to

how OpenSSL behaves in non-blocking mode:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;// Reads the response of a pipeline (simplified).

// This is a hand-wired generator.

class read_response_fsm {

public:

// User-supplied arguments: request and response

read_response_fsm(const request&amp;amp; req, response_handler_ref handler);

// Yielded to signal that we should read from the server

struct read_args { span&amp;lt;std::byte&amp;gt; buffer; };

// Yielded to signal that we're done

struct done_args { system::error_code result; };

variant&amp;lt;read_args, done_args&amp;gt;

resume(connection_state&amp;amp;, system::error_code io_result, std::size_t bytes_transferred);

};

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The idea is that higher-level code should call &lt;code&gt;resume&lt;/code&gt; until it returns

a &lt;code&gt;done_args&lt;/code&gt; value. This allows de-coupling from the underlying I/O runtime.&lt;/p&gt;

&lt;p&gt;Since NativePG targets C++20, I’m considering rewriting this as a coroutine.

Boost.Capy (currently under development - hopefully part of Boost soon)

could be a good candidate for this.&lt;/p&gt;

&lt;h2 id=&quot;putting-everything-together-the-asio-interface&quot;&gt;Putting everything together: the Asio interface&lt;/h2&gt;

&lt;p&gt;At the end of the day, most users just want a &lt;code&gt;connection&lt;/code&gt; object they can easily

use. Once all the sans-io parts are working, writing it is pretty straight-forward.

This is what end user code looks like:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;// Create a connection

connection conn{co_await asio::this_coro::executor};

// Connect

co_await conn.async_connect(

{.hostname = &quot;localhost&quot;, .username = &quot;postgres&quot;, .password = &quot;&quot;, .database = &quot;postgres&quot;}

);

std::cout &amp;lt;&amp;lt; &quot;Startup complete\n&quot;;

// Compose our request and response

request req;

req.add_query(&quot;SELECT * FROM libs WHERE author = $1&quot;, {&quot;Ruben&quot;});

std::vector&amp;lt;library&amp;gt; libs;

// Run the request

co_await conn.async_exec(req, into(libs));

&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&quot;auto-batch-connections&quot;&gt;Auto-batch connections&lt;/h2&gt;

&lt;p&gt;While &lt;code&gt;connection&lt;/code&gt; is good, experience has shown me that it’s still

too low-level for most users:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Connection establishment is manual with &lt;code&gt;async_connect&lt;/code&gt;.&lt;/li&gt;

&lt;li&gt;No built-in reconnection or health checks.&lt;/li&gt;

&lt;li&gt;No built-in concurrent execution of requests.

That is, &lt;code&gt;async_exec&lt;/code&gt; first writes the request, then reads the response.

Other requests may not be executed during this period.

This limits the connection’s throughput.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;For this reason, NativePG will provide some higher-level interfaces

that will make server communication easier and more efficient.

To get a feel of what we need, we should first understand

the two main usage patterns that we expect.&lt;/p&gt;

&lt;p&gt;Most of the time, connections are used in a &lt;strong&gt;stateless&lt;/strong&gt; way.

For example, consider querying data from the server:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;request req;

req.add_query(&quot;SELECT * FROM libs WHERE author = $1&quot;, {&quot;Ruben&quot;});

co_await conn.async_exec(req, res);

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;This query is not mutating connection state in any way.

Other queries could be inserted before and after it without

making any difference.&lt;/p&gt;

&lt;p&gt;I plan to add a higher-level connection type, similar to

&lt;code&gt;redis::connection&lt;/code&gt; in Boost.Redis, that automatically

batches concurrent requests and handles reconnection.

The key differences with &lt;code&gt;connection&lt;/code&gt; would be:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Several independent tasks can share an auto-batch connection.

This is an error for &lt;code&gt;connection&lt;/code&gt;.&lt;/li&gt;

&lt;li&gt;If several requests are queued at the same time,

the connection may send them together to the server using a single system call.&lt;/li&gt;

&lt;li&gt;There is no &lt;code&gt;async_connect&lt;/code&gt; in an auto-batch connection.

Reconnection is handled automatically.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;Note that this pattern is not exclusive to read-only or

individual queries. Transactions can work by using protocol features:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;request req;

req.set_autosync(false); // All subsequent queries are part of the same transaction

req.add_query(&quot;UPDATE table1 SET x = $1 WHERE y = 2&quot;, {42});

req.add_query(&quot;UPDATE table2 SET x = $1 WHERE y = 42&quot;, {2});

req.add_sync(); // The two updates run atomically

co_await conn.async_exec(req, res);

&lt;/code&gt;&lt;/pre&gt;

&lt;h2 id=&quot;connection-pools&quot;&gt;Connection pools&lt;/h2&gt;

&lt;p&gt;I mentioned there were two main usage scenarios in the library.

Sometimes, it is required to use connections in a &lt;strong&gt;stateful&lt;/strong&gt; way:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;request req;

req.add_simple_query(&quot;BEGIN&quot;); // start a transaction manually

req.add_query(&quot;SELECT * FROM library WHERE author = $1 FOR UPDATE&quot;, {&quot;Ruben&quot;}); // lock rows

co_await conn.async_exec(req, lib);

// Do something in the client that depends on lib

if (lib.id == &quot;Boost.MySQL&quot;)

co_return; // don't

// Now compose another request that depends on what we read from lib

req.clear();

req.add_query(&quot;UPDATE library SET status = 'deprecated' WHERE id = $1&quot;, {lib.id});

req.add_simple_query(&quot;COMMIT&quot;);

co_await conn.async_exec(req, ignore);

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The key point here is that this pattern requires exclusive access to &lt;code&gt;conn&lt;/code&gt;.

No other requests should be interleaved between the first and the second

&lt;code&gt;async_exec&lt;/code&gt; invocations.&lt;/p&gt;

&lt;p&gt;The best way to solve this is by using a connection pool.

This is what client code could look like:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-cpp&quot;&gt;co_await pool.async_exec([&amp;amp;] (connection&amp;amp; conn) -&amp;gt; asio::awaitable&amp;lt;system::error_code&amp;gt; {

request req;

req.add_simple_query(&quot;BEGIN&quot;);

req.add_query(&quot;SELECT balance, status FROM accounts WHERE user_id = $1 FOR UPDATE&quot;, {user_id});

account_info acc;

co_await conn.async_exec(req, into(acc));

// Check if account has sufficient funds and is active

if (acc.balance &amp;lt; payment_amount || acc.status != &quot;active&quot;)

co_return error::insufficient_funds;

// Call external payment gateway API - this CANNOT be done in SQL

auto result = co_await payment_gateway.process_charge(user_id, payment_amount);

// Compose next request based on the external API response

req.clear();

if (result.success) {

req.add_query(

&quot;UPDATE accounts SET balance = balance - $1 WHERE user_id = $2&quot;,

{payment_amount, user_id}

);

req.add_simple_query(&quot;COMMIT&quot;);

}

co_await conn.async_exec(req, ignore);

// The connection is automatically returned to the pool when this coroutine completes

co_return result.success ? error_code{} : error::payment_failed;

});

&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;I explicitly want to avoid having a &lt;code&gt;connection_pool::async_get_connection()&lt;/code&gt;

function, like in Boost.MySQL. This function returns a proxy object that grants access

to a free connection. When destroyed, the connection is returned to the pool.

This pattern looks great on paper, but runs into severe complications in

multi-threaded code. The proxy object’s destructor needs to mutate the pool’s state,

thus needing at least an &lt;code&gt;asio::dispatch&lt;/code&gt; to the pool’s executor, which may or may not

be a strand. It is so easy to get wrong that Boost.MySQL added a &lt;code&gt;pool_params::thread_safe&lt;/code&gt; boolean

option to take care of this automatically, adding extra complexity. Definitely something to avoid.&lt;/p&gt;

&lt;h2 id=&quot;sql-formatting&quot;&gt;SQL formatting&lt;/h2&gt;

&lt;p&gt;As we’ve seen, the protocol has built-in support for adding

parameters to queries (see placeholders like &lt;code&gt;$1&lt;/code&gt;). These placeholders

are expanded in the server securely.&lt;/p&gt;

&lt;p&gt;While this covers most cases, sometimes we need to generate SQL

that is too dynamic to be handled by the server. For instance,

a website might allow multiple optional filters, translating into

&lt;code&gt;WHERE&lt;/code&gt; clauses that might or might not be present.&lt;/p&gt;

&lt;p&gt;These use cases require SQL generated in the client. To do so,

we need a way of formatting user-supplied values without

running into SQL injection vulnerabilities. The final piece

of the library becomes a &lt;code&gt;format_sql&lt;/code&gt; function akin to the

one in Boost.MySQL.&lt;/p&gt;

&lt;h2 id=&quot;final-thoughts&quot;&gt;Final thoughts&lt;/h2&gt;

&lt;p&gt;While the plan is clear, there is still much to be done here.

There are dedicated APIs for high-throughput data copying and

push notifications that need to be implemented. Some of the described

APIs have a solid working implementation, while others still need

some work. All in all, I hope that this library can soon reach a state

where it can be useful to people.&lt;/p&gt;</content><author><name></name></author><category term="ruben" /><summary type="html">Do you know Boost.MySQL? If you’ve been reading my posts, you probably do. Many people have wondered ‘why not Postgres?’. Well, the time is now. TL;DR: I’m writing the equivalent of Boost.MySQL, but for PostgreSQL. You can find the code here. Since libPQ is already a good library, the NativePG project intends to be more ambitious than Boost.MySQL. In addition to the expected Asio interface, I intend to provide a sans-io API that exposes primitives like message serialization. Throughout this post, I will go into the intended library design and the rationales behind its design. The lowest level: message serialization PostgreSQL clients communicate with the server using a binary protocol on top of TCP, termed the frontend/backend protocol. The protocol defines a set of messages used for interactions. For example, when running a query, the following happens: ┌────────┐ ┌────────┐ │ Client │ │ Server │ └───┬────┘ └───┬────┘ │ │ │ Query │ │ ──────────────────────────────────────────&amp;gt; │ │ │ │ RowDescription │ │ &amp;lt;────────────────────────────────────────── │ │ │ │ DataRow │ │ &amp;lt;────────────────────────────────────────── │ │ │ │ CommandComplete │ │ &amp;lt;────────────────────────────────────────── │ │ │ │ ReadyForQuery │ │ &amp;lt;────────────────────────────────────────── │ │ │ In the lowest layer, this library provides functions to serialize and parse such messages. The goal here is being as efficient as possible. Parsing functions are non-allocating, and use an approach inspired by Boost.Url collections: Parsing database types The PostgreSQL type system is quite rich. In addition to the usual SQL built-in types, it supports advanced scalars like UUIDs, arrays and user-defined aggregates. When running a query, libPQ exposes retrieved data as either raw text or bytes. This is what the server sends in the DataRow packets shown above. To do something useful with the data, users likely need parsing and serializing such types. The next layer of NativePG is in charge of providing such functions. This will likely contain some extension points for users to plug in their types. This is the general form of such functions: system::error_code parse(span&amp;lt;const std::byte&amp;gt; from, T&amp;amp; to, const connection_state&amp;amp;); void serialize(const T&amp;amp; from, dynamic_buffer&amp;amp; to, const connection_state&amp;amp;); Note that some types might require access to session configuration. For instance, dates may be expressed using different wire formats depending on the connection’s runtime settings. At the time of writing, only ints and strings are supported, but this will be extended soon. Composing requests Efficiency in database communication is achieved with pipelining. A network round-trip with the server is worth a thousand allocations in the client. It is thus critical that: The protocol properly supports pipelining. This is the case with PostgreSQL. The client should expose an interface to it, and make it very easy to use. libPQ does the first, and NativePG intends to achieve the second. NativePG pipelines by default. In NativePG, a request object is always a pipeline: // Create a request request req; // These two queries will be executed as part of a pipeline req.add_query(&quot;SELECT * FROM libs WHERE author = $1&quot;, {&quot;Ruben&quot;}); req.add_query(&quot;DELETE FROM libs WHERE author &amp;lt;&amp;gt; $1&quot;, {&quot;Ruben&quot;}); Everything you may ask the server can be added to request. This includes preparing and executing statements, establishing pipeline synchronization points, and so on. It aims to be close enough to the protocol to be powerful, while also exposing high-level functions to make things easier. Reading responses Like request, the core response mechanism aims to be as close to the protocol as possible. Since use cases here are much more varied, there is no single response class, but a concept, instead. This is what a response_handler looks like: struct my_handler { // Check that the handler is compatible with the request, // and prepare any required data structures. Called once at the beginning handler_setup_result setup(const request&amp;amp; req, std::size_t pipeline_offset); // Called once for every message received from the server // (e.g. `RowDescription`, `DataRow`, `CommandComplete`) void on_message(const any_request_message&amp;amp; msg); // The overall result of the operation (error_code + diagnostic string). // Called after the operation has finished. const extended_error&amp;amp; result() const; }; Note that on_message is not allowed to report errors. Even if a handler encounters a problem with a message (imagine finding a NULL for a field where the user isn’t expecting one), this is a user error, rather than a protocol error. Subsequent steps in the pipeline must not be affected by this. This is powerful but very low-level. Using this mechanism, the library exposes an interface to parse the result of a query into a user-supplied struct, using Boost.Describe: struct library { std::int32_t id; std::string name; std::string cpp_version; }; BOOST_DESCRIBE_STRUCT(library, (), (id, name, cpp_version)) // ... std::vector&amp;lt;library&amp;gt; libs; auto handler = nativepg::into(libs); // this is a valid response_handler Network algorithms Given a user request and response handler, how do we send these to the server? We need a set of network algorithms to achieve this. Some of these are trivial: sending a request to the server is an asio::write on the request’s buffer. Others, however, are more involved: Reading a pipeline response needs to verify that the message sequence is what we expected, for security, and handle errors gracefully. The handshake algorithm, in charge of authentication when we connect to the server, needs to respond to server authentication challenges, which may come in different forms. Writing these using asio::async_compose is problematic because: They become tied to Boost.Asio. They are difficult to test. They result in long compile times and code bloat due to templating. At the moment, these are written as finite state machines, similar to how OpenSSL behaves in non-blocking mode: // Reads the response of a pipeline (simplified). // This is a hand-wired generator. class read_response_fsm { public: // User-supplied arguments: request and response read_response_fsm(const request&amp;amp; req, response_handler_ref handler); // Yielded to signal that we should read from the server struct read_args { span&amp;lt;std::byte&amp;gt; buffer; }; // Yielded to signal that we're done struct done_args { system::error_code result; }; variant&amp;lt;read_args, done_args&amp;gt; resume(connection_state&amp;amp;, system::error_code io_result, std::size_t bytes_transferred); }; The idea is that higher-level code should call resume until it returns a done_args value. This allows de-coupling from the underlying I/O runtime. Since NativePG targets C++20, I’m considering rewriting this as a coroutine. Boost.Capy (currently under development - hopefully part of Boost soon) could be a good candidate for this. Putting everything together: the Asio interface At the end of the day, most users just want a connection object they can easily use. Once all the sans-io parts are working, writing it is pretty straight-forward. This is what end user code looks like: // Create a connection connection conn{co_await asio::this_coro::executor}; // Connect co_await conn.async_connect( {.hostname = &quot;localhost&quot;, .username = &quot;postgres&quot;, .password = &quot;&quot;, .database = &quot;postgres&quot;} ); std::cout &amp;lt;&amp;lt; &quot;Startup complete\n&quot;; // Compose our request and response request req; req.add_query(&quot;SELECT * FROM libs WHERE author = $1&quot;, {&quot;Ruben&quot;}); std::vector&amp;lt;library&amp;gt; libs; // Run the request co_await conn.async_exec(req, into(libs)); Auto-batch connections While connection is good, experience has shown me that it’s still too low-level for most users: Connection establishment is manual with async_connect. No built-in reconnection or health checks. No built-in concurrent execution of requests. That is, async_exec first writes the request, then reads the response. Other requests may not be executed during this period. This limits the connection’s throughput. For this reason, NativePG will provide some higher-level interfaces that will make server communication easier and more efficient. To get a feel of what we need, we should first understand the two main usage patterns that we expect. Most of the time, connections are used in a stateless way. For example, consider querying data from the server: request req; req.add_query(&quot;SELECT * FROM libs WHERE author = $1&quot;, {&quot;Ruben&quot;}); co_await conn.async_exec(req, res); This query is not mutating connection state in any way. Other queries could be inserted before and after it without making any difference. I plan to add a higher-level connection type, similar to redis::connection in Boost.Redis, that automatically batches concurrent requests and handles reconnection. The key differences with connection would be: Several independent tasks can share an auto-batch connection. This is an error for connection. If several requests are queued at the same time, the connection may send them together to the server using a single system call. There is no async_connect in an auto-batch connection. Reconnection is handled automatically. Note that this pattern is not exclusive to read-only or individual queries. Transactions can work by using protocol features: request req; req.set_autosync(false); // All subsequent queries are part of the same transaction req.add_query(&quot;UPDATE table1 SET x = $1 WHERE y = 2&quot;, {42}); req.add_query(&quot;UPDATE table2 SET x = $1 WHERE y = 42&quot;, {2}); req.add_sync(); // The two updates run atomically co_await conn.async_exec(req, res); Connection pools I mentioned there were two main usage scenarios in the library. Sometimes, it is required to use connections in a stateful way: request req; req.add_simple_query(&quot;BEGIN&quot;); // start a transaction manually req.add_query(&quot;SELECT * FROM library WHERE author = $1 FOR UPDATE&quot;, {&quot;Ruben&quot;}); // lock rows co_await conn.async_exec(req, lib); // Do something in the client that depends on lib if (lib.id == &quot;Boost.MySQL&quot;) co_return; // don't // Now compose another request that depends on what we read from lib req.clear(); req.add_query(&quot;UPDATE library SET status = 'deprecated' WHERE id = $1&quot;, {lib.id}); req.add_simple_query(&quot;COMMIT&quot;); co_await conn.async_exec(req, ignore); The key point here is that this pattern requires exclusive access to conn. No other requests should be interleaved between the first and the second async_exec invocations. The best way to solve this is by using a connection pool. This is what client code could look like: co_await pool.async_exec([&amp;amp;] (connection&amp;amp; conn) -&amp;gt; asio::awaitable&amp;lt;system::error_code&amp;gt; { request req; req.add_simple_query(&quot;BEGIN&quot;); req.add_query(&quot;SELECT balance, status FROM accounts WHERE user_id = $1 FOR UPDATE&quot;, {user_id}); account_info acc; co_await conn.async_exec(req, into(acc)); // Check if account has sufficient funds and is active if (acc.balance &amp;lt; payment_amount || acc.status != &quot;active&quot;) co_return error::insufficient_funds; // Call external payment gateway API - this CANNOT be done in SQL auto result = co_await payment_gateway.process_charge(user_id, payment_amount); // Compose next request based on the external API response req.clear(); if (result.success) { req.add_query( &quot;UPDATE accounts SET balance = balance - $1 WHERE user_id = $2&quot;, {payment_amount, user_id} ); req.add_simple_query(&quot;COMMIT&quot;); } co_await conn.async_exec(req, ignore); // The connection is automatically returned to the pool when this coroutine completes co_return result.success ? error_code{} : error::payment_failed; }); I explicitly want to avoid having a connection_pool::async_get_connection() function, like in Boost.MySQL. This function returns a proxy object that grants access to a free connection. When destroyed, the connection is returned to the pool. This pattern looks great on paper, but runs into severe complications in multi-threaded code. The proxy object’s destructor needs to mutate the pool’s state, thus needing at least an asio::dispatch to the pool’s executor, which may or may not be a strand. It is so easy to get wrong that Boost.MySQL added a pool_params::thread_safe boolean option to take care of this automatically, adding extra complexity. Definitely something to avoid. SQL formatting As we’ve seen, the protocol has built-in support for adding parameters to queries (see placeholders like $1). These placeholders are expanded in the server securely. While this covers most cases, sometimes we need to generate SQL that is too dynamic to be handled by the server. For instance, a website might allow multiple optional filters, translating into WHERE clauses that might or might not be present. These use cases require SQL generated in the client. To do so, we need a way of formatting user-supplied values without running into SQL injection vulnerabilities. The final piece of the library becomes a format_sql function akin to the one in Boost.MySQL. Final thoughts While the plan is clear, there is still much to be done here. There are dedicated APIs for high-throughput data copying and push notifications that need to be implemented. Some of the described APIs have a solid working implementation, while others still need some work. All in all, I hope that this library can soon reach a state where it can be useful to people.</summary></entry><entry><title type="html">Systems, CI Updates Q4 2025</title><link href="http://cppalliance.org/sam/2026/01/22/SamsQ4Update.html" rel="alternate" type="text/html" title="Systems, CI Updates Q4 2025" /><published>2026-01-22T00:00:00+00:00</published><updated>2026-01-22T00:00:00+00:00</updated><id>http://cppalliance.org/sam/2026/01/22/SamsQ4Update</id><content type="html" xml:base="http://cppalliance.org/sam/2026/01/22/SamsQ4Update.html">&lt;h3 id=&quot;doc-previews-and-doc-builds&quot;&gt;Doc Previews and Doc Builds&lt;/h3&gt;

&lt;p&gt;The pull request to isomorphic-git “Support git commands run in submodules” was merged, and released in the latest version. (See previous post for an explanation). The commit modified 153 files, all the git api commands, and tests applying to each one. The next step is for upstream Antora to adjust package.json and refer to the newer isomorphic-git so it will be distributed along with Antora. Since isomorphic-git is more widely used than just Antora, their userbase is already field testing the new version.&lt;/p&gt;

&lt;p&gt;Created an antora extension https://github.com/cppalliance/antora-downloads-extension that will retry ui-bundle downloads. The Boost Superproject builds sometimes fail because of Antora download failures. I am now in the process of rolling out this extension to all affected repositories. It must be included in each playbook if that playbook downloads the bundle as part of the build process.&lt;/p&gt;

&lt;p&gt;Adjusted doc previews to update the existing PR comments instead of posting many new ones, to reduce the email spam effect. The job will modify a timestamp in the PR comment which allows developers to see the most recent build time and if the pages rebuilt successfully. I needed to solve some puzzles to implement this, since usually Jenkins jobs are stateless and don’t know if they previously posted a comment, or which comment it was that should be modified across subsequent jobs runs. It turns out there is a feature “Build with Parameters”, and properties/parameters can be saved in the job.&lt;/p&gt;

&lt;h3 id=&quot;boost-website-boostorgwebsite-v2&quot;&gt;Boost website boostorg/website-v2&lt;/h3&gt;

&lt;p&gt;Lowered the CPU threshold on the horizontal pod autoscaler to scale pods more rapidly when there is increased traffic.&lt;/p&gt;

&lt;p&gt;When web visitors go to the wrong domain or URL, set the redirects to 301 “moved permanently”. Reduced the number of redirect hops by sending visitors directly to the final URL www.boost.org.&lt;/p&gt;

&lt;p&gt;Investigated a bug where PDF files were timing out and crashing the server. Those should not be parsed by beautiful soup or lxml.&lt;/p&gt;

&lt;p&gt;During this quarter we published boost 1.90.0. Worked closely with the release managers to resolve problems during the release. The boost.org website was not fully updating after importing the new version.&lt;/p&gt;

&lt;p&gt;Meetings about CMS feature, other topics. Many general discussions about website issues.&lt;/p&gt;

&lt;h3 id=&quot;mailman3&quot;&gt;Mailman3&lt;/h3&gt;

&lt;p&gt;When unmoderating a new user on mailman3 an administrator must click a drop-down and select “Default Processing” so this subscriber may send emails directly to the list and not continue to be moderated. I have started developing an enhancement in Postorius whereby there is one simple button “Accept and Unmoderate” thus streamlining the process. However as often happens with new and radical ideas sent to the Mailman maintainers, they put up roadblocks. While I believe the new feature is promising, and it is helpful to quickly unmoderate users, without skipping that step, the future of the pull request is uncertain.&lt;/p&gt;

&lt;h3 id=&quot;boost-ci&quot;&gt;boost-ci&lt;/h3&gt;

&lt;p&gt;Created a Fastly CDN mirror of keyserver.ubuntu.com at keyserver.boost.org. If keyserver.ubuntu.com experiences occasional outages but keys are cached on the CDN mirror, then CI jobs will be able to proceed without difficulty. Configured both Drone and boost-ci to use the CDN at keyserver.boost.org.&lt;/p&gt;

&lt;h3 id=&quot;jenkins&quot;&gt;Jenkins&lt;/h3&gt;

&lt;p&gt;Beast2 doc previews. Capy previews. JSON lcov jobs. Openmethod doc previews.&lt;/p&gt;

&lt;p&gt;Modified email notifications to send ‘recovery’ type messages after failed jobs. Other enhancements to Jenkins jobs.&lt;/p&gt;

&lt;h3 id=&quot;boost-release-process-boostorgrelease-tools&quot;&gt;Boost release process boostorg/release-tools&lt;/h3&gt;

&lt;p&gt;When building releases with publish-release.py, generate “nodocs” copies of the Boost releases and upload them to archives.boost.io. The “nodocs” versions are now functional. If anyone would like to accelerate their CI build process, set the target URL to nodocs such as: https://archives.boost.io/release/1.90.0/source-nodocs/boost_1_90_0.tar.gz .&lt;/p&gt;

&lt;p&gt;Migrated the release workstation instance from GCP to AWS so that during the next Boost release 1.91.0 the server will be closer to AWS S3, allowing file uploads to transfer faster. Designed a mechanism that resizes the server instance on a cron schedule via GHA. Most of the time it’s quite small, but during releases the server is allocated more CPU.&lt;/p&gt;

&lt;h3 id=&quot;drone&quot;&gt;Drone&lt;/h3&gt;

&lt;p&gt;Microsoft Windows - VS2026 container image.&lt;br /&gt;

Ubuntu 25.10 container image.&lt;/p&gt;

&lt;h3 id=&quot;gha&quot;&gt;GHA&lt;/h3&gt;

&lt;p&gt;Added CI jobs to build “documentation” in the boostorg/container repository. GHA will test doc builds, which helps when debugging modifications to documentation.&lt;/p&gt;

&lt;p&gt;Fil-C is a “fanatically compatible memory-safe implementation of C and C++.” https://github.com/pizlonator/fil-c Upon request, I composed an example Fil-C GitHub Actions job at https://github.com/sdarwin/fil-c-demo which was then applied by developers in other Boost repositories.&lt;/p&gt;</content><author><name></name></author><category term="sam" /><summary type="html">Doc Previews and Doc Builds The pull request to isomorphic-git “Support git commands run in submodules” was merged, and released in the latest version. (See previous post for an explanation). The commit modified 153 files, all the git api commands, and tests applying to each one. The next step is for upstream Antora to adjust package.json and refer to the newer isomorphic-git so it will be distributed along with Antora. Since isomorphic-git is more widely used than just Antora, their userbase is already field testing the new version. Created an antora extension https://github.com/cppalliance/antora-downloads-extension that will retry ui-bundle downloads. The Boost Superproject builds sometimes fail because of Antora download failures. I am now in the process of rolling out this extension to all affected repositories. It must be included in each playbook if that playbook downloads the bundle as part of the build process. Adjusted doc previews to update the existing PR comments instead of posting many new ones, to reduce the email spam effect. The job will modify a timestamp in the PR comment which allows developers to see the most recent build time and if the pages rebuilt successfully. I needed to solve some puzzles to implement this, since usually Jenkins jobs are stateless and don’t know if they previously posted a comment, or which comment it was that should be modified across subsequent jobs runs. It turns out there is a feature “Build with Parameters”, and properties/parameters can be saved in the job. Boost website boostorg/website-v2 Lowered the CPU threshold on the horizontal pod autoscaler to scale pods more rapidly when there is increased traffic. When web visitors go to the wrong domain or URL, set the redirects to 301 “moved permanently”. Reduced the number of redirect hops by sending visitors directly to the final URL www.boost.org. Investigated a bug where PDF files were timing out and crashing the server. Those should not be parsed by beautiful soup or lxml. During this quarter we published boost 1.90.0. Worked closely with the release managers to resolve problems during the release. The boost.org website was not fully updating after importing the new version. Meetings about CMS feature, other topics. Many general discussions about website issues. Mailman3 When unmoderating a new user on mailman3 an administrator must click a drop-down and select “Default Processing” so this subscriber may send emails directly to the list and not continue to be moderated. I have started developing an enhancement in Postorius whereby there is one simple button “Accept and Unmoderate” thus streamlining the process. However as often happens with new and radical ideas sent to the Mailman maintainers, they put up roadblocks. While I believe the new feature is promising, and it is helpful to quickly unmoderate users, without skipping that step, the future of the pull request is uncertain. boost-ci Created a Fastly CDN mirror of keyserver.ubuntu.com at keyserver.boost.org. If keyserver.ubuntu.com experiences occasional outages but keys are cached on the CDN mirror, then CI jobs will be able to proceed without difficulty. Configured both Drone and boost-ci to use the CDN at keyserver.boost.org. Jenkins Beast2 doc previews. Capy previews. JSON lcov jobs. Openmethod doc previews. Modified email notifications to send ‘recovery’ type messages after failed jobs. Other enhancements to Jenkins jobs. Boost release process boostorg/release-tools When building releases with publish-release.py, generate “nodocs” copies of the Boost releases and upload them to archives.boost.io. The “nodocs” versions are now functional. If anyone would like to accelerate their CI build process, set the target URL to nodocs such as: https://archives.boost.io/release/1.90.0/source-nodocs/boost_1_90_0.tar.gz . Migrated the release workstation instance from GCP to AWS so that during the next Boost release 1.91.0 the server will be closer to AWS S3, allowing file uploads to transfer faster. Designed a mechanism that resizes the server instance on a cron schedule via GHA. Most of the time it’s quite small, but during releases the server is allocated more CPU. Drone Microsoft Windows - VS2026 container image. Ubuntu 25.10 container image. GHA Added CI jobs to build “documentation” in the boostorg/container repository. GHA will test doc builds, which helps when debugging modifications to documentation. Fil-C is a “fanatically compatible memory-safe implementation of C and C++.” https://github.com/pizlonator/fil-c Upon request, I composed an example Fil-C GitHub Actions job at https://github.com/sdarwin/fil-c-demo which was then applied by developers in other Boost repositories.</summary></entry><entry><title type="html">Containers galore</title><link href="http://cppalliance.org/joaquin/2026/01/18/Joaquins2025Q4Update.html" rel="alternate" type="text/html" title="Containers galore" /><published>2026-01-18T00:00:00+00:00</published><updated>2026-01-18T00:00:00+00:00</updated><id>http://cppalliance.org/joaquin/2026/01/18/Joaquins2025Q4Update</id><content type="html" xml:base="http://cppalliance.org/joaquin/2026/01/18/Joaquins2025Q4Update.html">&lt;p&gt;During Q4 2025, I’ve been working in the following areas:&lt;/p&gt;

&lt;h3 id=&quot;boostbloom&quot;&gt;Boost.Bloom&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Written &lt;a href=&quot;https://bannalia.blogspot.com/2025/10/bulk-operations-in-boostbloom.html&quot;&gt;an article&lt;/a&gt; explaining

the usage and implementation of the recently introduced bulk operations.&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;boostunordered&quot;&gt;Boost.Unordered&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Written maintenance fixes

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/320&quot;&gt;PR#320&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/321&quot;&gt;PR#321&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/326&quot;&gt;PR#326&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/327&quot;&gt;PR#327&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/328&quot;&gt;PR#328&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/unordered/pull/335&quot;&gt;PR#335&lt;/a&gt;.&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;boostmultiindex&quot;&gt;Boost.MultiIndex&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Refactored the library to use Boost.Mp11 instead of Boost.MPL (&lt;a href=&quot;https://github.com/boostorg/multi_index/pull/87&quot;&gt;PR#87&lt;/a&gt;),

remove pre-C++11 variadic argument emulation (&lt;a href=&quot;https://github.com/boostorg/multi_index/pull/88&quot;&gt;PR#88&lt;/a&gt;)

and remove all sorts of pre-C++11 polyfills (&lt;a href=&quot;https://github.com/boostorg/multi_index/pull/90&quot;&gt;PR#90&lt;/a&gt;).

These changes are explained in &lt;a href=&quot;https://bannalia.blogspot.com/2025/12/boostmultiindex-refactored.html&quot;&gt;an article&lt;/a&gt;

and will be shipped in Boost 1.91. Transition is expected to be mostly backwards

compatible, though two Boost libraries needed adjustments as they use MultiIndex

in rather advanced ways (see below).&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;boostflyweight&quot;&gt;Boost.Flyweight&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Adapted the library to work with Boost.MultiIndex 1.91

(&lt;a href=&quot;https://github.com/boostorg/flyweight/pull/25&quot;&gt;PR#25&lt;/a&gt;).&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;boostbimap&quot;&gt;Boost.Bimap&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Adapted the library to work with Boost.MultiIndex 1.91

(&lt;a href=&quot;https://github.com/boostorg/bimap/pull/50&quot;&gt;PR#50&lt;/a&gt;).&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;other-boost-libraries&quot;&gt;Other Boost libraries&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Helped set up the Antora-based doc build chain for DynamicBitset

(&lt;a href=&quot;https://github.com/boostorg/dynamic_bitset/pull/96&quot;&gt;PR#96&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/dynamic_bitset/pull/97&quot;&gt;PR#97&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/dynamic_bitset/pull/98&quot;&gt;PR#98&lt;/a&gt;).&lt;/li&gt;

&lt;li&gt;Same with OpenMethod

(&lt;a href=&quot;https://github.com/boostorg/openmethod/pull/40&quot;&gt;PR#40&lt;/a&gt;).&lt;/li&gt;

&lt;li&gt;Fixed concept compliance of iterators provided by Spirit

(&lt;a href=&quot;https://github.com/boostorg/spirit/pull/840&quot;&gt;PR#840&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/spirit/pull/841&quot;&gt;PR#841&lt;/a&gt;).&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;experiments-with-fil-c&quot;&gt;Experiments with Fil-C&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;https://fil-c.org/&quot;&gt;Fil-C&lt;/a&gt; is a C and C++ compiler built on top of LLVM that adds run-time

memory-safety mechanisms preventing out-of-bounds and use-after-free accesses.

I’ve been experimenting with compiling Boost.Unordered test suite with Fil-C and running

some benchmarks to measure the resulting degradation in execution times and memory usage.

Results follow:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;Articles

&lt;ul&gt;

&lt;li&gt;&lt;a href=&quot;https://bannalia.blogspot.com/2025/11/some-experiments-with-boostunordered-on.html&quot;&gt;Some experiments with Boost.Unordered on Fil-C&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html&quot;&gt;Comparing the run-time performance of Fil-C and ASAN&lt;/a&gt;&lt;/li&gt;

&lt;/ul&gt;

&lt;/li&gt;

&lt;li&gt;Repos

&lt;ul&gt;

&lt;li&gt;&lt;a href=&quot;https://github.com/joaquintides/fil-c_boost_unordered&quot;&gt;Compiling Boost.Unordered test suite with Fil-C&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;https://github.com/boostorg/boost_unordered_benchmarks/tree/boost_unordered_flat_map_fil-c&quot;&gt;Benchmarks of Fil-C and ASAN against baseline&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;https://github.com/boostorg/boost_unordered_benchmarks/tree/boost_unordered_flat_map_fil-c_memory&quot;&gt;Memory consumption of Fil-C and ASAN with respect to baseline&lt;/a&gt;&lt;/li&gt;

&lt;/ul&gt;

&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;proof-of-concept-of-a-semistable-vector&quot;&gt;Proof of concept of a semistable vector&lt;/h3&gt;

&lt;p&gt;By “semistable vector” I mean that pointers to the elements may be invalidated

upon insertion and erasure (just like a regular &lt;code&gt;std::vector&lt;/code&gt;) but iterators

to non-erased elements remain valid throughout.

I’ve written a small &lt;a href=&quot;https://github.com/joaquintides/semistable_vector/&quot;&gt;proof of concept&lt;/a&gt;

of this idea and measured its performance against non-stable &lt;code&gt;std::vector&lt;/code&gt; and fully

stable &lt;code&gt;std::list&lt;/code&gt;. It is dubious that such container could be of interest for production

use, but the techniques explored are mildly interesting and could be adapted, for

instance, to write powerful safe iterator facilities.&lt;/p&gt;

&lt;h3 id=&quot;teaser-exploring-the-stdhive-space&quot;&gt;Teaser: exploring the &lt;code&gt;std::hive&lt;/code&gt; space&lt;/h3&gt;

&lt;p&gt;In short, &lt;code&gt;std::hive&lt;/code&gt; (coming in C++26) is a container with stable references/iterators

and fast insertion and erasure. The &lt;a href=&quot;https://github.com/mattreecebentley/plf_hive&quot;&gt;reference implementation&lt;/a&gt;

for this container relies on a rather convoluted data structure, and I started to wonder

if something simpler could deliver superior performance. Expect to see the results of

my experiments in Q1 2026.&lt;/p&gt;

&lt;h3 id=&quot;website&quot;&gt;Website&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;Filed issues

&lt;a href=&quot;https://github.com/boostorg/website-v2/issues/1936&quot;&gt;#1936&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/website-v2/issues/1937&quot;&gt;#1937&lt;/a&gt;,

&lt;a href=&quot;https://github.com/boostorg/website-v2/issues/1984&quot;&gt;#1984&lt;/a&gt;.&lt;/li&gt;

&lt;/ul&gt;

&lt;h3 id=&quot;support-to-the-community&quot;&gt;Support to the community&lt;/h3&gt;

&lt;ul&gt;

&lt;li&gt;I’ve been part of a task force with the C++ Alliance to review the entire

catalog of Boost libraries (170+) and categorize them according to their

maintainance status and relevance in light of additions to the C++

standard library over the years.&lt;/li&gt;

&lt;li&gt;Supporting the community as a member of the Fiscal Sponsorship Committee (FSC).&lt;/li&gt;

&lt;/ul&gt;</content><author><name></name></author><category term="joaquin" /><summary type="html">During Q4 2025, I’ve been working in the following areas: Boost.Bloom Written an article explaining the usage and implementation of the recently introduced bulk operations. Boost.Unordered Written maintenance fixes PR#320, PR#321, PR#326, PR#327, PR#328, PR#335. Boost.MultiIndex Refactored the library to use Boost.Mp11 instead of Boost.MPL (PR#87), remove pre-C++11 variadic argument emulation (PR#88) and remove all sorts of pre-C++11 polyfills (PR#90). These changes are explained in an article and will be shipped in Boost 1.91. Transition is expected to be mostly backwards compatible, though two Boost libraries needed adjustments as they use MultiIndex in rather advanced ways (see below). Boost.Flyweight Adapted the library to work with Boost.MultiIndex 1.91 (PR#25). Boost.Bimap Adapted the library to work with Boost.MultiIndex 1.91 (PR#50). Other Boost libraries Helped set up the Antora-based doc build chain for DynamicBitset (PR#96, PR#97, PR#98). Same with OpenMethod (PR#40). Fixed concept compliance of iterators provided by Spirit (PR#840, PR#841). Experiments with Fil-C Fil-C is a C and C++ compiler built on top of LLVM that adds run-time memory-safety mechanisms preventing out-of-bounds and use-after-free accesses. I’ve been experimenting with compiling Boost.Unordered test suite with Fil-C and running some benchmarks to measure the resulting degradation in execution times and memory usage. Results follow: Articles Some experiments with Boost.Unordered on Fil-C Comparing the run-time performance of Fil-C and ASAN Repos Compiling Boost.Unordered test suite with Fil-C Benchmarks of Fil-C and ASAN against baseline Memory consumption of Fil-C and ASAN with respect to baseline Proof of concept of a semistable vector By “semistable vector” I mean that pointers to the elements may be invalidated upon insertion and erasure (just like a regular std::vector) but iterators to non-erased elements remain valid throughout. I’ve written a small proof of concept of this idea and measured its performance against non-stable std::vector and fully stable std::list. It is dubious that such container could be of interest for production use, but the techniques explored are mildly interesting and could be adapted, for instance, to write powerful safe iterator facilities. Teaser: exploring the std::hive space In short, std::hive (coming in C++26) is a container with stable references/iterators and fast insertion and erasure. The reference implementation for this container relies on a rather convoluted data structure, and I started to wonder if something simpler could deliver superior performance. Expect to see the results of my experiments in Q1 2026. Website Filed issues #1936, #1937, #1984. Support to the community I’ve been part of a task force with the C++ Alliance to review the entire catalog of Boost libraries (170+) and categorize them according to their maintainance status and relevance in light of additions to the C++ standard library over the years. Supporting the community as a member of the Fiscal Sponsorship Committee (FSC).</summary></entry><entry><title type="html">Decimal is Accepted and Next Steps</title><link href="http://cppalliance.org/matt/2026/01/15/Matts2025Q4Update.html" rel="alternate" type="text/html" title="Decimal is Accepted and Next Steps" /><published>2026-01-15T00:00:00+00:00</published><updated>2026-01-15T00:00:00+00:00</updated><id>http://cppalliance.org/matt/2026/01/15/Matts2025Q4Update</id><content type="html" xml:base="http://cppalliance.org/matt/2026/01/15/Matts2025Q4Update.html">&lt;p&gt;After two reviews the Decimal (&lt;a href=&quot;https://github.com/cppalliance/decimal&quot;&gt;https://github.com/cppalliance/decimal&lt;/a&gt;) library has been accepted into Boost.

Look for it to ship for the first time with Boost 1.91 in the Spring.

For current and prospective users, a new release series (v6) is available on the releases page of the library.

This major version change contains all of the bug fixes and addresses comments from the second review.

We have once again overhauled the documentation based on the review to include a significant increase in the number of examples.

Between the &lt;code&gt;Basic Usage&lt;/code&gt; and &lt;code&gt;Examples&lt;/code&gt; tabs on the website we believe there’s now enough information to quickly make good use of the library.

One big quality of life worth highlighting for this version is that it ships with pretty printers for both GDB and LLDB.

It is a huge release (1108 commits with a diff stat of &amp;gt;50k LOC), but is be better than ever.

I expect that this is the last major version that will be released prior to moving to the Boost release cycle.&lt;/p&gt;

&lt;p&gt;Where to go from here?&lt;/p&gt;

&lt;p&gt;As I have mentioned in previous posts, the int128 (&lt;a href=&quot;https://github.com/cppalliance/int128&quot;&gt;https://github.com/cppalliance/int128&lt;/a&gt;) library started life as the backend for portable arithmetic and representation in the Decimal library.

It has since been expanded to include more of the standard library features that are unnecessary as a back-end, but useful to many people like &lt;code&gt;&amp;lt;format&amp;gt;&lt;/code&gt; support.

The last major update that I intend to make to the library prior to proposal for Boost is to add CUDA support.

This would not only add portability to another platform for many users, it would open the door for Decimal to also have CUDA support.

I will also be looking at a few of our performance measures as I think there are still places for improvement (such as signed 128-bit division).&lt;/p&gt;

&lt;p&gt;Lastly, towards the end of this quarter (March 5 - March 15), I will be serving as the review manager for Alfredo Correa’s Multi (&lt;a href=&quot;https://github.com/correaa/boost-multi&quot;&gt;https://github.com/correaa/boost-multi&lt;/a&gt;) library.

Multi is a modern C++ library that provides manipulation and access of data in multidimensional arrays for both CPU and GPU memory.

Feel free to give the library a go now and comment on what you find.

This is a very high quality library which should have an exciting review.&lt;/p&gt;</content><author><name></name></author><category term="matt" /><summary type="html">After two reviews the Decimal (https://github.com/cppalliance/decimal) library has been accepted into Boost. Look for it to ship for the first time with Boost 1.91 in the Spring. For current and prospective users, a new release series (v6) is available on the releases page of the library. This major version change contains all of the bug fixes and addresses comments from the second review. We have once again overhauled the documentation based on the review to include a significant increase in the number of examples. Between the Basic Usage and Examples tabs on the website we believe there’s now enough information to quickly make good use of the library. One big quality of life worth highlighting for this version is that it ships with pretty printers for both GDB and LLDB. It is a huge release (1108 commits with a diff stat of &amp;gt;50k LOC), but is be better than ever. I expect that this is the last major version that will be released prior to moving to the Boost release cycle. Where to go from here? As I have mentioned in previous posts, the int128 (https://github.com/cppalliance/int128) library started life as the backend for portable arithmetic and representation in the Decimal library. It has since been expanded to include more of the standard library features that are unnecessary as a back-end, but useful to many people like &amp;lt;format&amp;gt; support. The last major update that I intend to make to the library prior to proposal for Boost is to add CUDA support. This would not only add portability to another platform for many users, it would open the door for Decimal to also have CUDA support. I will also be looking at a few of our performance measures as I think there are still places for improvement (such as signed 128-bit division). Lastly, towards the end of this quarter (March 5 - March 15), I will be serving as the review manager for Alfredo Correa’s Multi (https://github.com/correaa/boost-multi) library. Multi is a modern C++ library that provides manipulation and access of data in multidimensional arrays for both CPU and GPU memory. Feel free to give the library a go now and comment on what you find. This is a very high quality library which should have an exciting review.</summary></entry><entry><title type="html">From Prototype to Product: MrDocs in 2025</title><link href="http://cppalliance.org/alan/2025/10/28/Alan.html" rel="alternate" type="text/html" title="From Prototype to Product: MrDocs in 2025" /><published>2025-10-28T00:00:00+00:00</published><updated>2025-10-28T00:00:00+00:00</updated><id>http://cppalliance.org/alan/2025/10/28/Alan</id><content type="html" xml:base="http://cppalliance.org/alan/2025/10/28/Alan.html">&lt;p&gt;In 2024, the &lt;a href=&quot;https://www.mrdocs.com&quot;&gt;MrDocs&lt;/a&gt; project was a &lt;strong&gt;fragile prototype&lt;/strong&gt;. It documented Boost.URL, but the &lt;strong&gt;CLI&lt;/strong&gt;, &lt;strong&gt;configuration&lt;/strong&gt;, and &lt;strong&gt;build process&lt;/strong&gt; were unstable. Most users could not run it without direct help from the core group. That unstable baseline is the starting point for this report.&lt;/p&gt;

&lt;p&gt;In 2025, we moved the codebase to &lt;strong&gt;minimum-viable-product&lt;/strong&gt; shape. I led the releases that stabilized the pipeline, aligned the &lt;strong&gt;configuration model&lt;/strong&gt;, and documented the work in this report to support a smooth &lt;strong&gt;leadership transition&lt;/strong&gt;. This post summarizes the &lt;strong&gt;2024 gaps&lt;/strong&gt;, the &lt;strong&gt;2025 fixes&lt;/strong&gt;, and the &lt;strong&gt;recommended directions&lt;/strong&gt; for the next phase.&lt;/p&gt;

&lt;!-- prettier-ignore --&gt;

&lt;ul id=&quot;markdown-toc&quot;&gt;

&lt;li&gt;&lt;a href=&quot;#system-overview&quot; id=&quot;markdown-toc-system-overview&quot;&gt;System Overview&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#2024-lessons-from-a-fragile-prototype&quot; id=&quot;markdown-toc-2024-lessons-from-a-fragile-prototype&quot;&gt;2024: Lessons from a Fragile Prototype&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#2025-from-prototype-to-mvp&quot; id=&quot;markdown-toc-2025-from-prototype-to-mvp&quot;&gt;2025: From Prototype to MVP&lt;/a&gt; &lt;ul&gt;

&lt;li&gt;&lt;a href=&quot;#v003-enforcing-consistency&quot; id=&quot;markdown-toc-v003-enforcing-consistency&quot;&gt;v0.0.3: Enforcing Consistency&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#v004-establishing-the-foundation&quot; id=&quot;markdown-toc-v004-establishing-the-foundation&quot;&gt;v0.0.4: Establishing the Foundation&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#v005-stabilization-and-public-readiness&quot; id=&quot;markdown-toc-v005-stabilization-and-public-readiness&quot;&gt;v0.0.5: Stabilization and Public Readiness&lt;/a&gt;&lt;/li&gt;

&lt;/ul&gt;

&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#2026-beyond-the-mvp&quot; id=&quot;markdown-toc-2026-beyond-the-mvp&quot;&gt;2026: Beyond the MVP&lt;/a&gt; &lt;ul&gt;

&lt;li&gt;&lt;a href=&quot;#strategic-prioritization&quot; id=&quot;markdown-toc-strategic-prioritization&quot;&gt;Strategic Prioritization&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#reflection&quot; id=&quot;markdown-toc-reflection&quot;&gt;Reflection&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#metadata&quot; id=&quot;markdown-toc-metadata&quot;&gt;Metadata&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#extensions-and-plugins&quot; id=&quot;markdown-toc-extensions-and-plugins&quot;&gt;Extensions and Plugins&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#dependency-resilience&quot; id=&quot;markdown-toc-dependency-resilience&quot;&gt;Dependency Resilience&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#follow-up-issues-for-v006&quot; id=&quot;markdown-toc-follow-up-issues-for-v006&quot;&gt;Follow-up Issues for v0.0.6&lt;/a&gt;&lt;/li&gt;

&lt;/ul&gt;

&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#acknowledgments&quot; id=&quot;markdown-toc-acknowledgments&quot;&gt;Acknowledgments&lt;/a&gt;&lt;/li&gt;

&lt;li&gt;&lt;a href=&quot;#conclusion&quot; id=&quot;markdown-toc-conclusion&quot;&gt;Conclusion&lt;/a&gt;&lt;/li&gt;

&lt;/ul&gt;

&lt;h2 id=&quot;system-overview&quot;&gt;System Overview&lt;/h2&gt;

&lt;p&gt;&lt;a href=&quot;https://www.mrdocs.com&quot;&gt;MrDocs&lt;/a&gt; is a C++ documentation generator built on &lt;strong&gt;Clang&lt;/strong&gt;. It parses source with full language fidelity, links declarations to their comments, and produces reference documentation that reflects real program structure—&lt;strong&gt;templates&lt;/strong&gt;, &lt;strong&gt;constraints&lt;/strong&gt;, and &lt;strong&gt;overloads&lt;/strong&gt; included.&lt;/p&gt;

&lt;blockquote&gt;

&lt;p&gt;Traditional tools often approximate the AST. MrDocs uses the AST directly, so documentation matches the code and modern C++ features render correctly.&lt;/p&gt;

&lt;/blockquote&gt;

&lt;p&gt;Unlike single-purpose generators, MrDocs separates the &lt;strong&gt;corpus&lt;/strong&gt; (semantic data) from the &lt;strong&gt;presentation layer&lt;/strong&gt;. Projects can choose among multiple &lt;strong&gt;output formats&lt;/strong&gt; or extend the system entirely: supply &lt;strong&gt;custom Handlebars templates&lt;/strong&gt; or script new generators using the &lt;strong&gt;plugin system&lt;/strong&gt;. The corpus is represented in the generators as a &lt;strong&gt;rich JSON-like DOM&lt;/strong&gt;. With schema files, MrDocs enables integration with &lt;strong&gt;build systems&lt;/strong&gt;, &lt;strong&gt;documentation frameworks&lt;/strong&gt;, or &lt;strong&gt;IDEs&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;From the user’s perspective, MrDocs behaves like a &lt;strong&gt;well-engineered CLI utility&lt;/strong&gt;. It accepts &lt;strong&gt;configuration files&lt;/strong&gt;, supports &lt;strong&gt;relative paths&lt;/strong&gt;, accepts custom &lt;strong&gt;build options&lt;/strong&gt;, and reports &lt;strong&gt;warnings&lt;/strong&gt; in a controlled, &lt;strong&gt;compiler-like&lt;/strong&gt; fashion. For C++ teams transitioning from &lt;strong&gt;Doxygen&lt;/strong&gt;, the &lt;strong&gt;command structure&lt;/strong&gt; is somewhat familiar, but the &lt;strong&gt;internal model&lt;/strong&gt; is designed for &lt;strong&gt;reproducibility&lt;/strong&gt; and &lt;strong&gt;correctness&lt;/strong&gt;. Our goal is not just to render &lt;strong&gt;reference pages&lt;/strong&gt; but to provide a &lt;strong&gt;reliable pipeline&lt;/strong&gt; that any C++ project seeking &lt;strong&gt;modern documentation infrastructure&lt;/strong&gt; can adopt.&lt;/p&gt;

&lt;script src=&quot;https://cdn.jsdelivr.net/npm/mermaid@11.12.0/dist/mermaid.min.js&quot;&gt;&lt;/script&gt;

&lt;div class=&quot;mermaid&quot;&gt;

graph LR

A[Source] --&amp;gt; B[Clang]

B --&amp;gt; C[Corpus]

C --&amp;gt; D{Plugin Layer}

subgraph Generator

E[HTML]

F[AsciiDoc]

G[XML]

G2[...]

end

D --&amp;gt; E

D --&amp;gt; F

D --&amp;gt; G

D --&amp;gt; G2

E --&amp;gt; H{Plugin Layer}

H --&amp;gt; H2[Published Docs]

F --&amp;gt; H

G --&amp;gt; H

G2 --&amp;gt; H

C --&amp;gt; I[Schema Export]

I --&amp;gt; J[Integrations&lt;br /&gt;IDEs &amp;amp; Build Systems]

&lt;/div&gt;

&lt;h2 id=&quot;2024-lessons-from-a-fragile-prototype&quot;&gt;2024: Lessons from a Fragile Prototype&lt;/h2&gt;

&lt;p&gt;MrDocs entered 2024 as a proof-of-concept built for Boost.URL. It could document one or two curated codebases and produce asciidoc pages for Antora, but the workflow stopped there. The CLI exposed only the scenarios we needed. Configuration options lived in internal notes. The only dependable build path was the script sequence we used inside the Alliance. External users hit errors and missing options almost immediately.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Stability was just as fragile:&lt;/strong&gt; We had no &lt;strong&gt;sanitizers&lt;/strong&gt;, no &lt;strong&gt;warnings-as-errors&lt;/strong&gt;, and inconsistent &lt;strong&gt;CI hardware&lt;/strong&gt;. The binaries crashed as soon as they saw unfamiliar code. The pipeline worked only when the input looked like Boost.URL. Point it at slightly different code patterns and it would segfault. Each feature landed as a custom patch, so logic duplicated across generators, and fixing one path broke another.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Early releases:&lt;/strong&gt; Release &lt;code&gt;v0.0.1&lt;/code&gt; captured that prototype: the early Handlebars engine, the HTML generator, the DOM refactor, and a list of APIs that only the core team could drive. &lt;code&gt;v0.0.2&lt;/code&gt; added structured configuration, automatic &lt;code&gt;compile_commands.json&lt;/code&gt;, and better SFINAE handling, but the tool was still insider-only.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Leadership transition:&lt;/strong&gt; Late in 2024 I became project lead with two initial priorities: &lt;strong&gt;document the gaps&lt;/strong&gt; and describe the &lt;strong&gt;true limits&lt;/strong&gt; of the system. That set the 2025 baseline—a functional prototype that needed &lt;strong&gt;coherence&lt;/strong&gt;, &lt;strong&gt;reproducibility&lt;/strong&gt;, and &lt;strong&gt;trust&lt;/strong&gt; before it could call itself a product.&lt;/p&gt;

&lt;p&gt;What 2025 later fixed were the weaknesses we saw here: configuration coherence, generator unification, schema validation, and basic options were all missing. The CLI, configuration files, and code drifted apart. Generators evolved independently with duplicated code and inconsistent naming. Editors had no schema to lean on. Extraction rules were ad hoc, which made the output incomplete. CI ran on an improvised matrix with no caching, sanitizers, or coverage, so regressions slipped through. That was the starting point.&lt;/p&gt;

&lt;blockquote&gt;

&lt;p&gt;Summary: 2024 produced a working demo, not a reproducible system. Each success exposed another weak link and clarified what had to change in 2025.&lt;/p&gt;

&lt;/blockquote&gt;

&lt;p&gt;In short:&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;2024 left us with a working prototype but no coherent architecture.&lt;/li&gt;

&lt;li&gt;The system could demonstrate the concept, but not sustain or reproduce it.&lt;/li&gt;

&lt;li&gt;Every improvement exposed another weak link, and every success demanded more structure than the system was built to handle.&lt;/li&gt;

&lt;li&gt;It was a year of learning by exhaustion—and setting the stage for everything that came next.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;Key 2024 checkpoints align with the timeline below:&lt;/p&gt;

&lt;script src=&quot;https://cdn.jsdelivr.net/npm/mermaid@11.12.0/dist/mermaid.min.js&quot;&gt;&lt;/script&gt;

&lt;div class=&quot;mermaid&quot;&gt;

%%{init: {&quot;theme&quot;: &quot;base&quot;, &quot;themeVariables&quot;: {&quot;primaryColor&quot;: &quot;#f7f9ff&quot;, &quot;primaryBorderColor&quot;: &quot;#9aa7e8&quot;, &quot;primaryTextColor&quot;: &quot;#1f2a44&quot;, &quot;lineColor&quot;: &quot;#b4bef2&quot;, &quot;secondaryColor&quot;: &quot;#fbf8ff&quot;, &quot;tertiaryColor&quot;: &quot;#ffffff&quot;, &quot;fontSize&quot;: &quot;14px&quot;}}}%%

timeline

title Prototypes

2024 Q1 : Boost.URL showcase

2024 Q2 : CLI gaps

2024 Q3 : Config + SFINAE fixes

2024 Q4 : Leadership transition

&lt;/div&gt;

&lt;h1 id=&quot;2025-from-prototype-to-mvp&quot;&gt;2025: From Prototype to MVP&lt;/h1&gt;

&lt;p&gt;I started the year with a gap analysis that compared MrDocs to other C++ documentation pipelines. From that review I defined the minimum viable product and three priority tracks. &lt;strong&gt;Usability&lt;/strong&gt; covered workflows and surface area that make adoption simple. &lt;strong&gt;Stability&lt;/strong&gt; covered deterministic behavior, proper data structures, and CI discipline. &lt;strong&gt;Foundation&lt;/strong&gt; covered configuration and data models that keep code, flags, and documentation aligned. The 2025 releases followed those tracks and turned MrDocs from a proof of concept into a tool that other teams can adopt.&lt;/p&gt;

&lt;ul&gt;

&lt;li&gt;&lt;strong&gt;v0.0.3 — Consistency.&lt;/strong&gt; We replaced ad-hoc behavior with a coherent system: a single source of truth for configuration kept CLI, config files, and docs in sync; generators and templates were unified so changes propagate by design; core semantic extraction (e.g., concepts, constraints, SFINAE) became reliable; and CI hardened around reproducible, tested outputs across HTML and Antora.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;v0.0.4 — Foundation.&lt;/strong&gt; We introduced precise warning controls and a family of &lt;code&gt;extract-*&lt;/code&gt; options to match established tooling, added a JSON Schema for configuration (enabling editor validation/autocomplete), delivered a robust reference system for documentation comments, brought initial inline formatting to generators, and simplified onboarding with a cross-platform bootstrap script. CI gained sanitizers, coverage checks, and modern compilers.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;v0.0.5 — Stabilization.&lt;/strong&gt; We redesigned documentation metadata to support recursive inline elements, enforced safer polymorphic types with optional references and non-nullable patterns, and added user-facing improvements (sorting, automatic compilation database detection, quick reference indices, improved namespace/overload grouping, LLDB formatters). The website and documentation UI were refreshed for accessibility and responsiveness, new demos (including self-documentation) were published, and CI was further tightened with stricter policies and cross-platform bootstrap enhancements.&lt;/li&gt;

&lt;/ul&gt;

&lt;p&gt;Together, these releases executed the roadmap derived from the initial gap analysis: they &lt;strong&gt;aligned&lt;/strong&gt; the moving parts, &lt;strong&gt;closed&lt;/strong&gt; the most important capability gaps, and delivered a &lt;strong&gt;stable foundation&lt;/strong&gt; that future work can extend without re-litigating fundamentals.&lt;/p&gt;

&lt;script src=&quot;https://cdn.jsdelivr.net/npm/mermaid@11.12.0/dist/mermaid.min.js&quot;&gt;&lt;/script&gt;

&lt;div class=&quot;mermaid&quot;&gt;

%%{init: {&quot;theme&quot;: &quot;base&quot;, &quot;themeVariables&quot;: {

&quot;primaryColor&quot;: &quot;#e4eee8&quot;,

&quot;primaryBorderColor&quot;: &quot;#affbd6&quot;,

&quot;primaryTextColor&quot;: &quot;#000000&quot;,

&quot;lineColor&quot;: &quot;#baf9d9&quot;,

&quot;secondaryColor&quot;: &quot;#f0eae4&quot;,

&quot;tertiaryColor&quot;: &quot;#ebeaf4&quot;,

&quot;fontSize&quot;: &quot;14px&quot;

}}}%%

mindmap

root((MVP Evolution))

v0.0.3

Config sync

Shared templates

CI discipline

v0.0.4

Warning controls

Schema

Bootstrap

v0.0.5

Recursive docs

Nav refresh

Tooling polish

&lt;/div&gt;

&lt;h2 id=&quot;v003-enforcing-consistency&quot;&gt;v0.0.3: Enforcing Consistency&lt;/h2&gt;

&lt;p&gt;&lt;code&gt;v0.0.3&lt;/code&gt; is where MrDocs stopped being a collection of one-off special cases and became a coherent system. Before this release, features landed in a single generator and drifted from the others; extraction handled only the narrowly requested pattern and crashed on nearby ones; and options were inconsistent—some hard-coded, some missing from CLI/config, with no mechanism to keep code, docs, and flags aligned.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What changed:&lt;/strong&gt; The &lt;code&gt;v0.0.3&lt;/code&gt; release fixes this foundation. We introduced a single source of truth for &lt;strong&gt;configuration options&lt;/strong&gt; with TableGen-style metadata: docs, the config file, and the CLI always stay in sync. We added essential Doxygen-like options to make basic projects immediately usable and filled obvious gaps in symbols and doc comments.&lt;/p&gt;

&lt;p&gt;We implemented metadata extraction for &lt;strong&gt;core symbol types&lt;/strong&gt; and their information—such as template constraints, &lt;strong&gt;concepts&lt;/strong&gt;, and &lt;strong&gt;automatic SFINAE&lt;/strong&gt; detection. We &lt;strong&gt;unified generators&lt;/strong&gt; and templates so changes propagate by design, added &lt;strong&gt;tagfile support&lt;/strong&gt; and “lightweight reflection” to documentation comments as &lt;strong&gt;lazy DOM objects&lt;/strong&gt; and arrays, and &lt;strong&gt;extended Handlebars&lt;/strong&gt; to power the new generators. These features allowed us to create the initial version of the &lt;strong&gt;website&lt;/strong&gt; and ensure the documentation is always in sync.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Build and testing discipline:&lt;/strong&gt; CI, builds, and tests were hardened. All generators were now tested, &lt;strong&gt;LLVM caching&lt;/strong&gt; systems improved, and we launched our first &lt;strong&gt;macOS release&lt;/strong&gt; (important for teams working on Antora UI bundles). All of this long tail of performance, correctness, and safety work turned “works on my machine” into repeatable, adoptable output across HTML and Antora.&lt;/p&gt;

&lt;p&gt;&lt;code&gt;v0.0.3&lt;/code&gt; was the inflection point. For the first time, developers could depend on consistent configuration, &lt;strong&gt;shared templates&lt;/strong&gt;, and predictable behavior across generators. It aligned internal tools, eliminated duplicated effort, and replaced trial-and-error debugging with &lt;strong&gt;reproducible builds&lt;/strong&gt;. Every improvement in later versions built on this foundation.&lt;/p&gt;

&lt;details&gt;

&lt;summary&gt;Categorized improvements for v0.0.3&lt;/summary&gt;

&lt;ul&gt;

&lt;li&gt;&lt;strong&gt;Configuration Options&lt;/strong&gt;: enforcing consistency, reproducible builds, and transparent reporting

&lt;ul&gt;

&lt;li&gt;Enforce configuration options are in sync with the JSON source of truth (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/a1fb8ec6f23ef0802626329d7ab1e5c4635c52a7&quot; title=&quot;refactor(generate-config-info): normalization via visitor&quot;&gt;a1fb8ec6&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/9daf71fe0539a3a6b926560a15e65fdbd6343356&quot; title=&quot;refactor: info nodes configuration file&quot;&gt;9daf71fe&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;File and symbol filters (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/1b67a847db83f329af6cb9f059da7fa071939593&quot; title=&quot;feat: file and symbol filters&quot;&gt;1b67a847&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/b352ba223db0ad0b3d5f7283072b5dffb95eab1e&quot; title=&quot;feat: symbol filters listed on docs&quot;&gt;b352ba22&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;Reference and symbol configuration (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/a3e4477f699e1c5c4d489239ad559f9d51823272&quot; title=&quot;feat: reference, symbol options&quot;&gt;a3e4477f&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/30eaabc9a28aa3282bbe9e5b0c8b0e4a2c2c817f&quot; title=&quot;docs: reference, symbol options&quot;&gt;30eaabc9&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;Extraction options (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/41411db2848e1fab628dc62ee2e1831628b5d4c7&quot; title=&quot;feat: extraction options&quot;&gt;41411db2&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/1214d94bcf3597bd69caacd5b2648f677d4d197d&quot; title=&quot;docs: extraction options&quot;&gt;1214d94b&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;Reporting options (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/f994e47e318d852cc17cd026f7d7cdbcf3df0c5f&quot; title=&quot;feat: reporting options&quot;&gt;f994e47e&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/0dd9cb45cf0168dec028aeb276bd03a419ba3a12&quot; title=&quot;docs: reporting options&quot;&gt;0dd9cb45&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;Configuration structure (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/c8662b35fc85dc142f0694f299bb000a0f8899be&quot; title=&quot;feat: use structured information for configuration&quot;&gt;c8662b35&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/dcf5beef5a4b8ea75b24364b9c8a8f2f56d5e6c8&quot; title=&quot;feat: generate config documentation&quot;&gt;dcf5beef&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/4bd3ea42420f20b6a45c545e7b61396567c3201f&quot; title=&quot;docs: configuration schema&quot;&gt;4bd3ea42&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;CLI workflows (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/a2dc4c7883917025f0b63b227be7476f3986fd1d&quot; title=&quot;feat: CLI orchestrator improvements&quot;&gt;a2dc4c78&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/3c0f90df53794a02d3c53d25aa4fa5c8a69fbaad&quot; title=&quot;docs: CLI quick reference&quot;&gt;3c0f90df&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;Warnings (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/4eab1933ff58330fb2c6753a648a26fba3038118&quot; title=&quot;docs: warnings&quot;&gt;4eab1933&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/5e586f2b03dd7b1eb5a45e51c904d8cbf4f63661&quot; title=&quot;feat: warnings&quot;&gt;5e586f2b&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/0e2dd713ebde919bf0ebc231d9a5795eb99b0d25&quot; title=&quot;feat: warning when configuration references missing include directories&quot;&gt;0e2dd713&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;SettingsDB (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/225b2d50835485b746c766df8993e1bb66938d17&quot; title=&quot;feat: settings DB&quot;&gt;225b2d50&lt;/a&gt;, &lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/51639e77b629f00c02aa11afe41a01e12804ef63&quot; title=&quot;feat: settings db generator&quot;&gt;51639e77&lt;/a&gt;)&lt;/li&gt;

&lt;li&gt;Deterministic configuration (&lt;a href=&quot;https://github.com/cppalliance/mrdocs/commit/b544974105efc225af0af7f9952ef96338fe4c44&quot; title=&quot;feat: deterministic configuration order&quot;&gt;b5449741&lt;/a&gt;)&lt;/li&gt;