- Boost - lists.boost.org

[container] New deque implementation and future plans
by Ion Gaztañaga 10 Oct '25

10 Oct '25

Hi, I've been working lately on a new deque implementation for Boost.Container. The original uses the classic SGI STL-based data structure, that is quite bulky. The new implementation is already on develop and ready to be merged to master for Boost 1.90 The new implementation will try to be faster than std implementations (I probably need to work more on that with benchmarks), but more importantly, can allow some additional features. Some changes: - sizeof(deque) was 10 words, now is 4 words. Probably the lightest implementation around. - sizeof(deque::iterator) was 4 words, now is is 2 words (similar to libc++ and MSVC).) - Several internal algorithms were reimplemented to take advantage of the segmented nature of deque. - Defaults were slightly changed, 64 bit platforms now use 1024 byte blocks by default instead of the SGI classic 512 byte blocks (still far from libc++'s 4K blocks). - The new implementation eases further deque-like variations and optimizations in the future. Some planned features - Add a "stored_size_type" option so that the sizeof deque can be further decreased (probably down to 3 words) for those in 64 bit platforms that don't need more than 4G elements in deque. - Add a single-ended variation ("seque" might be confusing name because the data structure would not longer be a queue, but a segment-based sequence with random-access). Some people use deque to have a random-access container that avoids vector-like reallocations and guarantees stable pointers and references when inserting on the back. A double-ended container is sometimes sub-optimal for those use cases. - Add options (or maybe different containers or aliases reusing parts of the implementation) that can offer "reserve/capacity"-like features, so that a programmer can pre-allocate all the blocks that's going to use avoiding allocation performance penalties on hot code. I'll update the "Draft Development Plan for Boost.Container" (https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8…) with these proposals. Of course, I'm open to new proposals/features. If any booster is eager to test the new deque implementation or wants to suggest a benchmark/use-case that could be useful for Boost.Container users, please let me know! If anyone detects a bug in the new implementation please notify it and I'll try to solve it ASAP. Best, Ion

6 10

[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