- Boost - lists.boost.org

Minimum CMake version raised to 3.8
by Alexander Grund 02 Oct '25

02 Oct '25

Hi maintainers, the Boost superproject build now requires CMake 3.8 or higher. The reason for this is that the CMake feature `cxx_std_11` to declare the C++11 requirement was introduced in that version and is now used by a large amount of libraries, directly or indirectly. This change [1] was made due to users being confused about which CMake versions are required/supported (e.g. [2]). A couple libraries failed to declare the CMake 3.8 requirement even though they were using `cxx_std_11` leading to error messages that were not easy to understand to someone not used to CMake. I opened PRs fixing the requirements in a couple of repositories which I discovered during testing with a range of different CMake versions. Raising the minimum version to 3.8 reduces the number of versions to be tested with a low enough cost given the actual requirement by the many individual libraries and availability of that version (3.8 is old enough that it should be easily available to users, current versions are 3.31 and 4.1.) Note that some features of the Superproject require even higher versions: - BoostTestJamfile requires 3.9 - Automatic installation requires 3.13 So users should be using at least CMake 3.13 anyway. Stay safe! Alex [1] https://github.com/boostorg/boost/pull/1088 [2] https://github.com/boostorg/boost/pull/1081

1 0

[bloom] added bulk operations
by Joaquin M López Muñoz 01 Oct '25

01 Oct '25

For those interested in Boost.Bloom, I've just added bulk operations, which will make it into Boost 1.90: https://43.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html#tut… <https://43.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html#tut…> Joaquín M López Muñoz

2 2

Decimal Library re-review starting next week
by John Maddock 30 Sep '25

30 Sep '25

Just a quick reminder that the re-review of the decimal number library by Matt Borland and Chris Kormanyos starts next Monday the 6th of Oct. I know that Matt and Chris have been working hard to address the issues brought up during the first review, I filed these as bug reports and the original list and their resolutions can be seen here: https://github.com/cppalliance/decimal/issues?q=is%3Aissue%20state%3Aclosed… Looking forward to your feedback, John.

2 1

Streamlining the Release Archive?
by Vinnie Falco 30 Sep '25

30 Sep '25

Hi. A handful of contributors have looked into how we can streamline our website and the release package and there are two ideas which come up with regular periodicity: 1. Remove the unified documentation build 2. Split the Boost release into two archives: sources, and documentation The unified documentation build has a different layout in the release compared to the other libraries, which creates special cases for tooling. Splitting the Boost release gives an additional option to users who don’t need the documentation locally. Of course, what goes into these two new archives is completely up for discussion. Happy to hear everyone’s thoughts on this. Regards

5 8

Senior students eager to write a graduation work
by Antony Polukhin 25 Sep '25

25 Sep '25

Hi, I've got in touch with some professors in IT universities. They have a bunch of senior students that are in search of projects for their graduation work. Seems that Boost Libraries could benefit from that. Mentoring a senior student usually takes less time than implementing something on your own. Do you have any Boost related projects that could be done by students? Is there a list of such projects and mentors anywhere? -- Best regards, Antony Polukhin

4 4

End of regression runners?
by Tom Kent 23 Sep '25

23 Sep '25

(Try 3 at getting accepted by the mailing list) All- I just noticed that there was an issue causing regression runs to fail on both develop and master: the results end with this: boost-test(RUN) "math/test_autodiff_8" : "libs/math/test/test_autodiff_ 8.cpp" boost-test(COMPILE) "math/diff_autodiff_incl_test" : "libs/math/test/compile_test/diff_autodiff_incl_test.cpp" boost-test(COMPILE) "math/diff_finite_difference_incl_test" : "libs/math/test/compile_test/diff_finite_difference_incl_t est.cpp" boost-test(COMPILE) "math/diff_lanczos_smoothing_incl_test" : "libs/math/test/compile_test/diff_lanczos_smoothing_incl_t est.cpp" error: Unable to find file or target named error: 'my_autodiff_reverse_test.cpp' error: referred to from project at error: '../libs/math/test' In trying to figure out how long this had been happening, I went to the website(s) to see when the last good runs were, but pulling up those, it appears that the job that parses the results into the website hasn't been running since mid-june! https://regression.boost.io/master/developer/summary.html https://regression.boost.io/develop/developer/summary.html I had been happily running these runners for over a decade, even though they don't match the immediate feedback that a library author gets from a github actions job, running across *a lot* of different compilers seems useful, but apparently no one cares? Frankly (and obviously), I haven't spent as much time on care and feeding of the runners as I have in the past. It mostly comes down to rebooting the machines every couple months and updating to new gcc/clang/vs versions when they appear. **I'm looking for feedback from the community:** Let it go, not worth the electricity spent on running these (maybe move the infrastructure to github runners?) -or- Hey this could be useful, let's spend a couple cycles getting it back working again. Thanks, Tom

10 14

Potential risks in Boost testing and release workflow
by Mohammad Nejati 20 Sep '25

20 Sep '25

Hi everyone, There is a potential security concern regarding how Boost libraries are built and tested that might deserve some attention. Currently, it is common for the release manager or developers to build the superproject with all libraries and run all tests. This creates a risk that it only takes one malicious test to compromise the developer's or release manager's machine. Given the size of Boost and the number of libraries it contains, the chance that one library could include harmful code (especially in unit tests) is not negligible. The risk depends on the quality of maintenance for each individual library, which Boost has very little control over. I think the current process dates back to when Boost was a smaller set of libraries authored by trusted contributors. Today the situation is different, and there are more potential attack vectors. For example: Maintainer or contributor-related risks: While the risk is low for long-time trusted contributors, maintainers can change over time, especially for libraries that are under-maintained or abandoned and later picked up by volunteers. There is also a possibility that a contributor's credentials could be compromised and used against the Boost project in a targeted attack. Malicious pull requests: This may be the easiest way for an attacker to inject harmful code. Test-related PRs are especially risky, since they often involve large datasets or third-party code. CVE-2024-3094 shows how subtle such attacks can be. I believe it may no longer be safe to fully trust every individual library in the Boost collection. Changes to the release process might be necessary to reduce the chance of compromise. For example, the final machine that publishes shared libraries or Boost archives should not run tests. We might also recommend that developers clone only the libraries they actually depend on, rather than the full superproject. Given how B2 works, a library can execute an executable even if it is not part of a dependency chain. Thanks, Mohammad.

6 10

Looks like our CMake misses some of the b2 features
by Antony Polukhin 16 Sep '25

16 Sep '25

Hi, Looks like b2 was doing many things behind the scene and I've get used to it. Now I'm getting instantly hit by bugs because CMake misses the functionality. Below are some of the missing features ## Installation testing With b2 there is no need to test installation. It just works. CMake is different in that place, without CI scripts to test installation things break ( https://github.com/boostorg/dll/issues/102, https://github.com/boostorg/pfr/issues/217 ) ## CLI convenience cd libs/pfr/tests; ../../../b2 toolset=gcc14,gcc-15,clang-21 cxxstd=11,14,17,20,23,26 variant=debug, release and the library is tested in 36 configurations. CMake miss that functionality, and it also can not be run from libs/pfr/tests. Instead of that a list of libraries should be provided via CMake variable. Workarounds via CI matrix or shell scripts are clumsy and require copy pasting between Boost libraries. The same story with C++20 modules. If b2 was able to build modules, the syntax would be like modules=on. With CMake it is -DBOOST_USE_MODULES=1 -DCMAKE_EXPERIMENTAL_CXX_IMPORT_STD=0e5b6991-d74f-4b3d-a41c-cf096e0b2508 -G Ninja. ## Non-run tests CMake miss the compile, compile-fail, link, link-fail testing rules of b2 https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#bbv2.… ## Double efforts for build scripts Manual rewriting of Jamfiles to CMakeLists is boring and tiring. Keeping those two in sync is pain. ## Regression tests matrix The regression tests https://regression.boost.io/develop/developer/summary.html use b2. As a result cmake tests are limited to github CI only. # How to make things better In my naiive opinion many of the above issues could be bypassed by the following steps: 1) How about adjusting b2 to be able to run cmake? I mean it should under the hood convert b2 arguments into CMake arguments and run the cmake and tests. It can check for particular tests compile/link failures to emulate the missing cmake functionality. It could also run the the installation tests (test against an installed Boost library) 2) Can b2 fallback to CMake if there's no Jamfile? In that way the developers could transparently move from Jamfiles to CMake As a bonus, the following step could simplify the migration: 3) Can b2 be adjusted to generate CMakeLists from Jamfiles? Not necessary fully functional, but at least something to simplify the migration.

7 9

[sqlite] Review Result
by Mohammad Nejati 13 Sep '25

13 Sep '25

First of all, I would like to thank everyone who participated in the review process, and Klemens for submitting the library. In total, we received 9 reviews: 3 ACCEPT, 3 CONDITIONALLY ACCEPT, and 3 REJECT. The individual reviews are as follows: Barend Gehrels: ACCEPT [1] Ruben Perez: REJECT [2] Scott Bailey: ACCEPT [3] Mungo Gill: CONDITIONALLY ACCEPT [4] Amlal El Mahrouss: ACCEPT [5] Harold Bott: CONDITIONALLY ACCEPT [6] Darryl Green: CONDITIONALLY ACCEPT [7] Andrzej Krzemienski: REJECT [8] Maximilian Riemensberger: REJECT [9] After carefully examining all reviews, going through the mailing list discussions, and consulting with Ruben Perez (author of Boost.MySQL) and Klemens, I have decided to REJECT the library due to critical flaws in the API and insufficient documentation. I strongly encourage the author to make another submission after addressing the issues listed below: - connection ownership ambiguity: A connection object can currently be constructed in two forms, owning and non-owning, which makes reasoning about it difficult. It was suggested on the mailing list to introduce a connection_ref type, which not only resolves this problem but also makes it easier for a user to wrap an existing sqlite3* (acquired from another library or C API) and benefit from the type safety provided by this library. - resultset ownership ambiguity: A resultset can either own an sqlite3_stmt or act as a non-owning reference to an existing sqlite3_stmt, providing only an access interface. This dual behavior makes reasoning about ownership difficult and allows multiple resultset objects to reference the same sqlite3_stmt, giving the false impression that they exist independently of the main statement object. Further exploration is needed to determine the right API. One suggestion from the mailing list is to remove the resultset type entirely and merge its functionality into the statement type, with a non-owning view/range type that can be used for iterating without having to pass the statement object around. - Wrong usage of cstring_ref (minor): As noted in the reviews, field::get_text could return a core::string_view instead of a cstring_ref, since SQLite already provides an API for determining the length of a column. - CI and test coverage: Currently, the CI supports only a limited set of platforms. It should, at a minimum, build and test the project on Linux, Windows, and macOS using Clang, GCC, and MSVC, with a matrix of configurations (RTTI on/off, exceptions on/off, shared/static). It should also include sanitizer builds and coverage reports. I would recommend that the author use the coverage report results to improve the tests, as the current tests do not appear to cover all interfaces. - Build scripts: The Jamfile should allow using libsqlite3 even when it is not installed system-wide and exists only in package manager paths, such as vcpkg. The necessary Jamfile for locating libsqlite3 should likely be added to the Boost.Build repository. - Examples: The existing examples cover advanced usage, such as SQLite virtual tables, but lack clear and simple use cases. I would recommend that the author focus on the most frequently used APIs and provide examples that quickly convey the knowledge needed to use the library for simple tasks. - Documentation: Currently, there is very little documentation around important types such as connection, statement, resultset, row, field, and value. I would recommend that the author provide proper documentation and usage examples for each type, and place extra emphasis on the quick-start section, as it is likely the part most users will read. - Real-world users: Considering the nature of this library, I would recommend that the author seek feedback from real-world users before submitting it again, as many design flaws in the libraries of this kind only become apparent through practical use. Without such feedback, it is difficult to anticipate usage patterns and design interfaces accordingly. Additionally, receiving reviews from users who have successfully used the library in their applications provides extra confidence to the release manager regarding the library's future success. [1] https://lists.boost.org/archives/list/boost@lists.boost.org/message/MGOXOV6… [2] https://lists.boost.org/archives/list/boost@lists.boost.org/message/57ZZ7II… [3] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BD3OQOW… [4] https://lists.boost.org/archives/list/boost@lists.boost.org/message/O477WE5… [5] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BUL75BO… [6] https://lists.boost.org/archives/list/boost@lists.boost.org/message/CS3FT3E… [7] https://lists.boost.org/archives/list/boost@lists.boost.org/message/VKZMFA6… [8] https://lists.boost.org/archives/list/boost@lists.boost.org/message/DIP5GYY… [9] https://lists.boost.org/archives/list/boost@lists.boost.org/message/TVXSK4D… Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

7 12

Spirit requires C++23 for questionable reasons
by Vinnie Falco 13 Sep '25

13 Sep '25

This new maintainer of Spirit has bumped up the language requirements to C++23, for what is in my opinion a gratuitous reason. To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience. While it is true that newer language features can make it easier for the maintainer to express the implementation, we make sacrifices (like writing `typename...type` instead of using the newer type trait aliases) for the convenience of users. This bump to C++23, which came without warning, has affected Boost.MQTT5 which must now scramble to fix itself before the next release. There should have been a warning for a version first. The Spirit author's rationale can be seen in this GitHub issue: https://github.com/boostorg/mqtt5/issues/36 Quoted here for convenience: > There's one political reason that I didn't mention: young people. > Why would a high school student who likes to experiment with C++ consider some obsolete > (C++17) library as attractive? Boost is dying and we're doomed if we don't use bleeding > edge features to attract young people. > You might think this is some kind of joke but I believe this is the right way to proceed. > > Young people will avoid contribution to the existing library if it sticks to the C++ standard that is > now obsolete for 2 versions. That was my feeling when I saw a C++03 library when I was a high > school student. I'm 30 years old now and still think the same. > > My goal is to revitalize C++. It is impossible without gathering contributions from the young people. > Some people write C++ for business, while some people write C++ because it's genuinely fun to hack. That's the difference. > It's the same reason that Rust is getting wider audience than C++. > > Many Japanese University students think otherwise. I have active connections to the > young community and they actually empathize with me. Thanks for the video anyways, > that is a good evidence that western, agitated-by-businessman young people are very > different than my colleagues. Thanks

14 41