- Boost - lists.boost.org

Boost.CI: Test with minimum CMake version
by Alexander Grund 30 Oct '25

30 Oct '25

Hi all, recently there were issues where the CMake build of individual libraries failed because features from a newer version than the requested minimum CMake version (`cmake_minimum_required(...)` in CMakeLists.txt) were used. This would be a bad UX in releases as the error in that case isn't really helpful. There was a recent discussion [3] about that. For that I introduced a new option for the Boost.CI "reusable" workflow: `min_cmake_version` [1] So additionally to running the CMake build with the "ubuntu-latest" runner and whatever CMake version is installed there (supposed to be "quite new") there is now an extra job that uses the CMake version specified in `min_cmake_version`. The default is CMake 3.16, which is the system CMake of Ubuntu 20. If you want to test against another CMake version, just add `min_cmake_version: x.y[.z]` to the `with:` key/section of the boost-ci call in your ci.yml A good idea is to use what you specified by `cmake_minimum_required` but you might need a higher version if a dependency requires a higher version. This is similar to the C++ standard: The minimum "propagates" to the dependents. In the boostorg/cmake repo there is a recently added workflow that tests the successful configuration of the Boost superproject with 26 different CMake versions. [2] Besides the usual trigger on commits and tags (important here e.g. the -beta tags prior to releases) a maintainer of this repo can trigger it manually for the master or develop branch of the super-project. This allows to check compatibility at any point in time. IIRC currently Peter is the (only?) maintainer of that repo, so you'd got to ask him to trigger this pipeline when necessary. Best Regards, Alex [1] https://github.com/boostorg/boost-ci/blob/96d19ca968a8ec530a656b50d0dbef4bb… [2] https://github.com/boostorg/cmake/blob/1b3a785d348420996c5cd5c9efe310aa2e9a… [3] https://github.com/boostorg/boost/pull/1081

1 0

Boost.Log Missed Performance Optmization ? Recursion unrolling in Attributes visitation
by Damien Buhl 28 Oct '25

28 Oct '25

Hello, I'm unsure if Andrey is reading the mailing list nowadays as it's been a while I didn't write here. But as I explained in my recent blog post, I discovered a missed optimization in Boost.Log, it seems the code implementing the attribute value visitation which is supposed to unroll up to 8 recursion, never unrolls them because nobody defines BOOST_LOG_VALUE_REF_VISITATION_VTABLE_SIZE : - https://tipi.build/blog/20250528-distributed#-meet-the-whistleblower-boostl… See https://github.com/boostorg/log/blob/2d932ddcb5b05a9b2cc0a9df2d8a6ff88883f2… I haven't an application on Boost.Log with enough hot code path to measure the performance impact of the unrolling, but I thought I would post it here, possibly this could improve the performance of some application. A workaround is to pass -DBOOST_LOG_VALUE_REF_VISITATION_VTABLE_SIZE=8 to get the unrolling to do what it was supposed to. Best Damien Buhl (alias daminetreg)

2 2

[release] New procedure for Boost 1.90 release notes
by Joaquin M López Muñoz 28 Oct '25

28 Oct '25

Hi everybody, As part of the evolution of the new website, the release notes procedure for the upcoming Boost 1.90 release is changing: BEFORE * Authors contributed their release notes as PRs to the file https://github.com/boostorg/website/blob/master/feed/history/boost_1_89_0.q… whose format was **Quickbook**. NOW * Authors should contribute their release notes as PRs to the file https://github.com/boostorg/website-v2-docs/blob/develop/release-notes/boos… whose format is **Asciidoc**. The procedure should be as straightforward as always. Asciidoc is in essence a Markdown variant, and the file already has some entry examples you can copy, adapt and paste. The following Asciidoc macros are available as a replacement to similarly-called Quickbook macros used before: https://github.com/cppalliance/asciidoctor-boost?tab=readme-ov-file#macros Currently there's no easy way to obtain a preview of the upcoming release notes, but I know the team in charge is working on this. Allow me to remind authors and contributors that now is an excellent time to add your entries to the release notes. If you have any doubts please post them here, or ask at the #boost Slack group. Thank you! Best, Joaquín M López Muñoz

1 0

utility::string_view and core::detail::string_view
by Vinnie Falco 25 Oct '25

25 Oct '25

On Thu, Oct 23, 2025 at 4:17 AM Dmitry Arkhipov via Boost < boost(a)lists.boost.org> wrote: > Url's and Charconv's maintainers decided > to not play along with the charade and reference boost::core::string_view > directly with the obvious drawback that that type is not documented > anywhere. > core::detail::string_view was added because this pull request FROM 2018 (seven years ago) was rejected: https://github.com/boostorg/utility/pull/51 We really need to fix this properly. In my opinion the maintainer of utility::string_view made the wrong choice when they rejected the pull request to make the constructors more useful. The consequence is that several Boost authors now use core::detail::string_view because it better satisfies user needs. At a time when people complain that Boost has its own version of std types, it would be best if we could come together and sort this. I would like to see the change which motivated core::detail::string view get applied to utility::string_view. Then we can change core::detail::string_view to be a deprecated alias, and after one release we can remove it. This solves everyone's problem: 1. Users get a type that works 2. Folks are not triggered by having two string views 3. Every library doesn't have to lift string_view into its own namespace 4. Cross-linking in documentation becomes possible With each new version of C++ we are asking more and more of Boost users. We are asking them to opt-in to our ecosystem which includes its own types similar yet sometimes incompatible with the standard types. It is our responsibility to make sure that we respect the user's trust, and deliver types which work for them. boost::utility::string_view breaks that trust at a time when we cannot afford to alienate. The consequence of the decision not to be flexible with the utility::string_view API is that now we have two string views. We have documentation issues. We have discovery issues. There is strife within the community. Yet more and more libraries are choosing core/detail/string_view.hpp instead of utility/string_view.hpp, simply because the core version works better. It is in the project's best interest to show the C++ community writ large that we can adapt and satisfy user needs. Lets do that by resolving the two string views. Thanks

3 2

BOOST_STATIC_ASSERT frowned up by core users
by Vinnie Falco 25 Oct '25

25 Oct '25

If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency. Thanks

9 32

[static_string] Desired behavior of to_static_[w]string() for floating point values
by Gennaro Prota 23 Oct '25

23 Oct '25

Hi everyone, I'd like to gather your input on the desired behavior of to_static_string() and to_static_wstring() when formatting floating point values. Currently, both functions mimic std::to_string() / std::to_wstring() as long as the result fits within the static string's capacity. If not, they fall back to scientific notation. However, C++26 introduces a breaking change: std::to_string() and std::to_wstring() will behave as if implemented via std::format() rather than s[w]printf(). For example, std::to_string( 0.1 ) will yield "0.1" instead of "0.100000". Given this shift, what behavior would you prefer for to_static_[w]string()? a) Match std::to_[w]string() and adopt the new behavior when compiling under C++26. b) Preserve the legacy behavior with fixed precision (6 digits) across all standard versions. c) Always behave as if using std::format(), even in pre-C++26 builds (breaking change). d) Other. Please let me know what you think. Thanks. -- Gennaro Prota <https://prota.dev>

8 16

Re: New depinst feature
by Dmitry Arkhipov 23 Oct '25

23 Oct '25

I just found out that the original email was mangled by my email client, so I am sending it again. You might know that recently we discovered a circular dependency between Graph and Geometry. Because of this I added a flag to depinst that causes it to detect dependency cycles and exit with an error. E.g. localy I get: $ python tools/boostdep/depinst/depinst.py graph -C Installing: config, headers, ../tools/boost_install, ../tools/build, ../tools/ cmake Installing: config, property_map, serialization, concept_check, iterator, unordered, optional, mpl, core, type_traits, static_assert, smart_ptr, assert, random, tuple, range, throw_exception, parameter, detail, foreach, move, utility, preprocessor, integer, container_hash, typeof, geometry, numeric/ conversion, multi_index, algorithm, bimap, array, math, spirit, lexical_cast, xpressive, any, property_tree, conversion, tti, function, regex Error: Dependency cycle detected: graph -> geometry -> graph I suggest we add jobs to our CI workflows that use the flag. Note that it's probably not a good idea to always use the flag, because then a cycle created by your dependency can break your CI jobs. If you are using boost-ci's common_install, the flag can be enabled by setting the environment variable DEPINST to "-C" or "--reject-cycles".

1 0

[release] Deadline for New Libraries and Breaking Changes is today!
by Marshall Clow 22 Oct '25

22 Oct '25

We’re starting the 1.90.0 release cycle. Upcoming milestones: 22-Oct - Boost 1.90.0 closed for new libraries and breaking changes 29-Oct - Boost 1.90.0 closed for major changes 05 -Nov- Boost 1.90.0 closed for beta As always, you can find the calendar here: https://www.boost.org/calendar/ — The release managers

1 0

[decimal] Late review on Boost.Decimal
by Michel Morin 22 Oct '25

22 Oct '25

Hi all, This is my (first) review of the Boost.Decimal library. First, I'd like to express my appreciation to Matt and Chris for their considerable work and dedication in developing this valuable library. <Background> I know the basics of IEEE 754 floating point. Since September, I've been experimenting with Boost.Decimal. I experimented with the library for several days both during the pre-review period and again during the main review period. <Initial experiments> My initial experience with the library was very smooth. The documentation offered useful examples and I was able to build and run without any problems on GCC, Clang, and Apple Clang. <Documentation> As I became more familiar with the library, I started to feel that the documentation was somewhat lacking. Some sections (e.g. `decimalXX_t`, literal support, <cstdlib> support, …) consist mostly of synopses with little explanatory text. As a result, I sometimes had to write and run small pieces of code to understand detailed behavior. It might be easier to follow if related topics were grouped together in the same section. For example, it could be clearer to place items such as - `from_chars` and `to_chars` (<charconv> support) - `strtod` family (<stdlib> support) under a common section like "IO and String Conversions". Early on, the links to the subsections in "Examples" on the left-side TOC were helpful. As I began using the later sections more, listing every Examples' subsection slowed access to them. Showing only a subset by default might improve navigation. This is a minor and subjective point. <Tests> Shortly after starting to use the library, I found a few bugs. While Matt handled the issue reports remarkably quickly, which I greatly appreciated, it was a bit surprising that they could be found easily. This suggests that the current test coverage might still be somewhat limited. As I mentioned in the main thread, using the decTest (General Decimal Arithmetic Testcases) could help identify such issues more systematically and improve the library's reliability. When using decTest, a few practical points may be worth noting: - The files prefixed with `ds`, `dd`, and `dq` correspond to decimal32, decimal64, and decimal128. - The decTest testcases are decarith-flavored (General Decimal Arithmetic Specification), meaning that they include behavior that goes beyond the IEEE 754 standard, such as additional rounding modes. Therefore, for example, testcases that use non-IEEE 754 rounding mode should be skipped, and testcases whose results are NaN should be compared in a relaxed manner (i.e. the comparison should ignore the sign and the payload). - The `ds…` testcases provide very limited coverage; porting testcases from `dd…` to decimal32 is likely more effective. - The bit patterns used in decTest are in DPD encoding. Since the testcases lack BID-specific edge cases, it would be useful to add testcases for non-canonical zeros (i.e. cases where the coefficient exceeds 10^p). For instance, when running `ddAdd.decTest`, 65 out of 971 testcases fail when comparing numerical results, and 286 out of 971 fail when comparing results bit by bit, which also verifies that the selected quantum is appropriate. <Conformance to IEEE 754> I understand that conformance to IEEE 754 may not be the library's primary goal, so this point might be less relevant. Still, I list conformance-related points below, since I personally believe that any library claiming to implement IEEE 754 should conform to the standard (possibly with very limited exceptions): * The default rounding mode is not the recommended one. - This is not a conformance violation, as the choice of the default rounding is only a recommendation. - **Fixed**. The default rounding mode is now the recommended one. * The mandatory operations do not satisfy correct rounding (CR). - **Documented** as a design decision. * FP exceptions are not supported. - **Documented** as a design decision. * For certain operations, the preferred quantum is not used. - This should be detectable with decTest. * Some IEEE 754 mandatory operations are not implemented. - In addition, `convertToInteger` family should round using a mode indicated by the function names (using a rounding mode parameter may also acceptable as in C23) rather than using the current rounding mode. Here are a few comments on the two design choices noted above: * CR on mandatory operations - It would help to document the downsides of not providing CR: * Even when using *reproducible* operations (see e.g. IEEE 754 Clause 11), results may diverge from CR libraries (e.g. Intel's decimal library). If a compiler's decimal FP backend uses such a CR library, results may also diverge from the C23 standard library. * When operations are not correctly rounded, the set of permissible results may contain more than one value. Therefore, even when limited to *reproducible* operations, different Boost.Decimal versions may produce different results. Adopting a faster algorithm, or later switching to a CR implementation, may change earlier results. - It would be helpful to document which operations are CR, including arithmetic operations and string-decimal conversions. * FP exception - It would also be beneficial to spell out what is not possible without FP exceptions. For example, callers cannot tell when rounding occurred. <Conclusion> I recommend **Conditional Accept**, on the condition that a setup is provided to run decTest regularly (e.g. as part of CI). As a wish list that is not a requirement, I would like to suggest the following: - The decTest results should be reasonably green; at least for the very basic operations, all testcases should pass. - It would be helpful to provide a mapping table between the IEEE 754 mandatory operations and the corresponding Boost.Decimal APIs, similar to the one found in C23 Clause F.2 or Section 9 of the Intel Decimal Floating-Point Math Library README. With these in place, I think that the library's conformance will be easier to assess and ongoing maintenance will be simpler over time. Thanks again to Matt and Chris for developing this valuable library, and to John for managing this review. Regards, Michel

2 2

[Graph] Interest in Verifying SSSP Results?
by HARRY QIAN 22 Oct '25

22 Oct '25

Hi all, The `dijkstra_shortest_paths()` function has a `distance_inf` parameter, which is supposed to be the greatest value of any `D` object, where `D` is the value type of the DistanceMap. When each edge in an input graph has weight less than `distance_inf` but the shortest path between two nodes has total distance more than `distance_inf`, `dijkstra_shortest_paths()` return the shortest path between these nodes as `distance_inf`. I could see that requiring the user to pre-validate the graph and make sure no distances surpass `distance_inf` is helpful for keeping the code concise. But in LEDA, another C++ graph library, I found a function `CHECK_SP()` which checks if the result of a single source shortest path computation is correct (including if any overflow occurred due to setting `distance_inf` too small). To my knowledge such a result-checking function doesn't exist in the Boost Graph Library. Would implementing a similar function for the BGL be reasonable? It could provide the user with a quick way to validate the outputs of shortest paths algorithm without bloating the code for dijkstra. Best, Harry

2 1