- Boost - lists.boost.org

[static_string] Removing support for BOOST_STATIC_STRING_STANDALONE?
by Gennaro Prota 09 Oct '25

09 Oct '25

Hi, while discussing a PR on GitHub (<https://github.com/boostorg/static_string/pull/67>), we ran into the question of whether BOOST_STATIC_STRING_STANDALONE should still be supported. What's your take on it? Personally, I lean toward minimizing conditional compilation wherever possible. Also, the macro is used to avoid dependencies which are easily avoided anyway, so why not avoiding them unconditionally and have "standalone mode" as the only option? -- Gennaro Prota <https://prota.dev>

5 6

A string_view with null-terminator guarantee?
by Andrzej Krzemienski 07 Oct '25

07 Oct '25

Hi Everyone, Would Boost libraries benefit from having a string_view-like type with the guarantee that the underlying character sequence is null-terminated? This could be as yet another Boost library, or as part of Boost.Core. Maybe Boost already has such a type somewhere? The need for such a type surfaces time and again. When a library needs to be passed both const char * and std::string cheaply, only to pass it down to low-level C-libraries later. We have seen one recently during the review of Boost.Sqlite. One is again proposed for standardization: wg21.link/p3655. Regards, &rzej;

16 40

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