October 2025 - Boost - lists.boost.org

utility::string_view and core::detail::string_view
by Vinnie Falco 14 Dec '25

14 Dec '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

15 54

A proposal for a modern build-system
by Hassan Sajjad 08 Dec '25

08 Dec '25

Hi. I compiled 25 Boost libraries with C++20 header-units, including examples and Tests of a few. This resulted in a 1.44x speed-up if we exclude the scanning. Scanning was as slow as the header-unit build. I have a solution for that. I am sending this paper (Making some final edits) https://htmlpreview.github.io/?https://github.com/HassanSajjad-302/iso-pape… , which allows for a build-system to use a scanning-less approach to build header-units.This method requires only minimal modifications to the compiler and enables memory-mapped file sharing, which significantly reduces filesystem overhead and further boosts speed. My proposal for a scanning-less approach will allow HMake to have another amazing feature, monolithic Big header-units. BigHu will allow you to map all the headers from a directory to a single header-unit. This header-unit includes all these header-files and consumes them as header-files. Now, whenever the compiler requests a header-unit from this directory, the build-system instead sends this consolidated BigHu. This will not only improve the clean build speed, because of fewer process launches. But also massively boosts the rebuild speed as few header-units need to be read instead of lots of files. No source-code editing will be needed to use this feature. And you will have the option to either build a library as BigHu (if you don't mean to edit it) or as small header-units (if you are working on it). HMake will soon support compile_commands.json, which I guess can work fine with header-units. Thus you can benefit from both, faster compilation and working intelliscence. The API shown in hmake.cpp is a work in progress. HMake build-system benefits are numerous, even if we leave out the header-units support. This makes it a perfect replacement for B2. I believe we can complete the switch in the next 2 months. And if some compiler supports my paper, we get >3x faster compilation as well. Best, Hassan Sajjad

28 88

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

03 Dec '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

3 5

Boost interprocess library using in python
by Murali Kishore 31 Oct '25

31 Oct '25

Hi, trying interprocess applications where Process A is cpp based and creates a shared memory segment and Process B from Python reads this shared memory. Is the boost interprocess library used in python ? If yes , share with me details on how to use it. -- Regards, Murali Kishore

2 1

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

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

24 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

Decimal Library review is now ended
by John Maddock 21 Oct '25

21 Oct '25

Just to confirm that the review of the decimal library has now come to an end. I'd like to thank everyone for some excellent discussion and great reviews, it might take me a while to collate all the information, but I'll be back with a result as soon as possible. Best, John.

1 0

Fwd: Boost.Decimal Review -- Attila Feher
by John Maddock 20 Oct '25

20 Oct '25

Forwarded here for archiving, with permission. -------- Forwarded Message -------- Subject: Boost.Decimal Review -- Attila Feher Date: Mon, 20 Oct 2025 14:34:21 -0000 From: Attila Feher (BLOOMBERG/ 919 3RD A) <afeher(a)bloomberg.net> Reply-To: Attila Feher <afeher(a)bloomberg.net> To: jz.maddock(a)googlemail.com CC: matt(a)mattborland.com, mungo.gill(a)me.com Attached is the review. CONDITIONALLY ACCEPTED See conditions in the text file. I hope it helps. Attila

1 0

End of Boost.Decimal Review
by John Maddock 20 Oct '25

20 Oct '25

Just to remind everyone that the Boost.Decimal review ends today, so if there are any last minute reviews, now's the time to get them in! Best, John.

1 0

Decimal Library re-review begins today
by John Maddock 20 Oct '25

20 Oct '25

The second review of the proposed Decimal Number library by Matt Borland and Chris Kormanyos begins today and runs until 15th Oct. You will find documentation here: https://develop.decimal.cpp.al/decimal/overview.html And the code repository is here: https://github.com/cppalliance/decimal/ Boost.Decimal is an implementation of IEEE 754 <https://standards.ieee.org/ieee/754/6210/> <https://standards.ieee.org/ieee/754/6210/%3E> and ISO/IEC DTR 24733 <https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf> <https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf%3E> Decimal Floating Point numbers. The library is header-only, has no dependencies, and requires C++14. This re-review is happening because the original review had an indeterminate result (see my summary at https://lists.boost.org/archives/list/boost@lists.boost.org/message/2Q7UBOT…) and resulted in my filing a number of issues against the library based on the reviewers comments. Now that Matt and Chris have been busy fixing these and addressing the reviewers concerns, the library is now back for a second look, see https://github.com/cppalliance/decimal/issues?q=is%3Aissue%20state%3Aclosed… for a complete list of issues addressed from the last review. I hope both the original reviewers, and new ones will come back for a second look. Please feel free to amend your original review, or if you're starting from scratch then please provide feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Do you already use it in industry? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions). Best, John Maddock (review manager).

15 85

New depinst feature
by Архипов Дмитрий 16 Oct '25

16 Oct '25

1 0

Decimal Review extended until Mon 20th.
by John Maddock 15 Oct '25

15 Oct '25

Folks, I've been made aware that there are a couple of knowledgeable people who would like to participate in the Decimal lib review but are currently away, in order to give them a little more time (along with anyone else who needs it), the review period is extended until Monday 20th. I'd like to thank everyone who has participated so far: we've had some great discussion. If you were thinking of submitting a review and haven't got around to it, now's your chance! Best, John Maddock.

1 0

[boost][decimal] LoS's review
by LoS 13 Oct '25

13 Oct '25

Dear Boosters, I'd first like to thank Matt for his effort in designing and implementing the library. Below, there's my review of the "Boost.Decimal" library. ## Documentation An issue is the inconsistent use of `using namespace` declarations in the code snippets. In some examples, the global declaration allows to write types simply as `decimal32_t`; in others, the examples omit the declaration, forcing to repeatedly write the full namespace, such as `boost::decimal::decimal32_t`. I think it'd be better to keep a consistent style throughout the documentation. The current documentation often lacks necessary detail for functions. While the synopsis and a generic description of the main classes (decimal32_t, decimal64_t, decimal128_t) are present, there's lack of information, like preconditions or edge-case behaviors, for many functions. Some examples aren't embedded directly in the documentation, but are merely mentioned as external files. While this prevents large blocks of code from cluttering the documentation, it imposes a burden on the user, who must manually navigate the repository to find these files. A much better solution would be to provide direct inks to these files. In this way, users could quickly jump to the code and return to the documentation, without the need to open a new browser window and manually look for the specific files. Finally, the "API Reference" section organizes some information using tables. While the tabular format is appropriate for structures where multiple fields must be summarized, its use to some types, like enums, seems arbitrary. Also, the visual display of these tables can be confusing upon first glance, since it may lead the user to incorrectly assume a relationship between adjacent, but functionally separate, tables. ## Design I think the use of explicit constructors should be more clearly defined. Some constructors are marked explicit, while others are not, and the reasoning for this difference isn't immediately clear. The "Design notes" section explains the decision to make constructors for floating-point numbers explicit. However, it omits any rationale for why constructors for integer types have been made non-explicit. I think that a complete explanation of the rationale behind constructor explicitness would be beneficial. About the documentation, the constructors, for both floating-point numbers and integers, are marked as explicit. This mismatch should be fixed, too. Best regards, LoS

2 1

[boost][decimal] Mungo's review
by mungo.gill＠me.com 13 Oct '25

13 Oct '25

Boost Decimal Review - Mungo Gill Firstly thank you to Matt for all the effort put into this sizable and clearly well thought out library. Here is my review of the Decimal library. - Background to this review I have used various floating point libraries in the past, mostly in financial applications, and am reasonably familiar with IEEE 754 for binary floating point, although I am less familiar with decimal floating point. I spent about a day writing small test programs, attempting to use it in my own code and stepping through function calls with the debugger. - Building and using I found the library relatively easy to download and use, the only exceptions being Windows ARM and assumptions made regarding fmtlib and format library availability (below). - - Compilation failures on Windows ARM When I tried to compile this on a Windows ARM (64-bit) box (using cmake and MSVC 2022), it failed due to the following error: …boost\decimal\detail\u256.hpp(691): error C3861: '_addcarry_u64': identifier not found (note: arm and arm64 windows probably need to be treated as a special case in the macro checks found in config.hpp lines 88-12. Note that on MSVC ARM the macro __ARM_NEON__ is not defined but arm_neon.h is provided as a header) - - fmtlib library support I tried building a program dependent on decimal on Windows (x64 built with cmake, MSVC 2022, C++20) and encountered an interesting issue: If the fmtlib library happens to be installed on the system then decimal attempts to #include the fmtlib library headers, encountering the following static_assert in fmt/base.h: static_assert(!FMT_UNICODE || use_utf8, "Unicode support requires compiling with /utf-8"); This occurred even though I had made no attempt (by this stage of testing) to write any code dependent upon either fmtlib or std::format. The checks in decimal/fmt_format.hpp should perhaps be tightened so that windows programs compiled without /utf-8 and which do not themselves use the fmtlib library do not give a compilation error. - - format library support The checks for whether or not the <format> header is available checks compiler versions. However, it is feasible that people are using a different standard library from the one you are assuming based on the compiler version (for example clang compilation may or may not have the -stdlib=libc++ flag, or someone might be using a modern clang with an older GNU libstdc++ lacking <format>). It would perhaps be more reliable to check for the __cpp_lib_format feature test macro that C++20 provides. - Points already mentioned by others in the mailing list As these have already been mentioned on the mailing list, I kept these points into their own section. - - Implicit conversions It is slightly confusing having implicit integer construction, but explicit floating point construction. Consider making all construction explicit. Although this leads to slightly more verbose user code, there is less opportunity for unintentioned conversions. Also confusing is the existence of a constructor taking a bool - for example the following code counter-intuitively prints 1 rather than the expected 3. I cannot personally imagine a good use case for wanting to implicitly convert a bool to a decimal. struct MyFloatType { double v_ = 3.14; operator int() const { return static_cast<int>(v_); } }; int main(int argc, char** argv) { MyFloatType f; boost::decimal::decimal64_t g(f); std::cout << g << std::endl; return 0; } - - Rounding I’m also not sure about the rounding convention being a global setting, and I’m not convinced thread-local overrides solve the problem. Perhaps some key functions could take an optional argument to override the global rounding setting ? - Other thoughts on the interface/design I thought this was a nice clean design, which covered most of what I would want covered by a decimal library. - - format library support The std::format support is somewhat lacking in flexibility, for example things like padding character specification (see https://en.cppreference.com/w/cpp/utility/format/spec.html) is not supported. (although I do appreciate that most standard library implementations don’t currently do the unicode width calculations correctly anyway, and supporting them would perhaps be excessive). Note: I did not do the same tests with the fmtlib library. - - locale support The level of locale support is undocumented. I would have included this in my documentation feedback but when I did a test I found that the implementation is also incomplete - i.e. it only appears to impact the decimal point specifier. Here is a simple reproducer (both output lines should be the same): std::locale a("en_US.utf8"); std::cout.imbue(a); std::cout << 1122.89 << std::endl; constexpr boost::decimal::decimal_fast64_t val4{ 112289, -2 }; std::cout << val4 << std::endl; - - cohort-aware functions Although I think the standard arithmetic operations and i/o should behave as they currently designed, there should be facilities to better exploit the fact that decimals can have different cohorts (for example facilities to add/subtract/multiply/divide where the resulting cohort is predictable and deterministic, albeit the preconditions would need to be quite tight to meet such requirements). A use of this would be to output a member of a cohort in a unique manner such that, when parsed, results in a decimal of the same cohort. - Other thoughts on the implementation Generally a good implementation, with clean, easy-to-follow code. I was able to step into operations using the debugger and did not find myself completely confused (although more code comments would always help :-) ) - - internal naming (this is an unduly picky point I know) The 32-bit, 64-bit and 128-bit implementations are called mul_impl, d64_mul_impl and d128_mul_impl. Perhaps for consistency the 32-bit should be d32_mul_impl. More notably, all 3 have comments talking about 128-bit arithmetic which looks to have been copied and pasted but which is not applicable to all 3. Similar points hold true for the division implementations. - - testing Although I understand the argument put forward in the mailing list that testing of special functions exercises the numerical precision, “interface testing” is quite light. For example a test that attempted to use a std::set<decimal32_t> would have quickly found the hashing issue mentioned in the mailing list. - Other thoughts on documentation Again, generally good, easy to read and understand documentation. Coming to this library for the first time I was quickly able to get up to speed. However, I did find myself having to look at the source code or the comments therein to find out how particular methods worked. - - Type conversions I may have missed it in the documentation, but the conversion rules between decimal types should be more clearly specified if they are not already (eg a decimal64_t can be converted to decimal128_fast_t but not to decimal32_fast_t). Also the documentation should specify the type promotion rules. For example, I failed to find in the documentation in the following code? constexpr boost::decimal::decimal_fast64_t val1{ 314, -2 }; constexpr boost::decimal::decimal64_t val2{ 2, 0 }; auto val3 = val1 * val2; - Conclusion My view would be that we should accept this library. Overall the documentation could be improved, and some useful features are missing, but in its current form (assuming the bugs and build issues mentioned above and in the mailing list are addressed) it is in a usable state and would be a useful addition to Boost.

2 4

[boost][decimal] Andrzej's review
by Andrzej Krzemienski 13 Oct '25

13 Oct '25

Hi Everyone, This is a review of the Boost.Decimal library. My knowledge about decimal floats is very superficial. In my job I need to deal with prices in all the World's currencies (string<->numeric conversion and simple additions and scaling) and for that I use a home-brew fixed-point implementation. I participated in the previous review, spent a couple of days studying the documentation, having a superficial look at tests and small pieces of implementation, running simple examples and filing bug reports. I would like to thank Matt and Chris for the huge effort to write and maintain this library, and for undergoing the painstaking process of Boost Review. The community needs this library, and I am happy that it is proposed for Boost. The nature of this library is very unusual: it implements types that belong in processors. We know it is needed for applications where accuracy and correctness is absolutely critical. Against other Boost libraries, it requires extreme measures for verifying correctness across the whole spectrum of values and cases. In a similar vein, in my opinion, it requires extremely detailed and comprehensive documentation. The bar should be higher than for an average Boost library. In this context, I have some concerns. While playing with the library I found three corner cases where it produces incorrect results: * https://github.com/cppalliance/decimal/issues/1091 * https://github.com/cppalliance/decimal/issues/1094 * https://github.com/cppalliance/decimal/issues/1119 Two are already fixed, and Matt has been very responsive, but I feel like it is too easy for a novice to find bugs in the library after a couple of minute's tests. It looks to me like the unit test "sieve" is still too coarse. Some test files (like test_decimal32.cpp or test_decimal64_basis.cpp) are commented out. Fuzz tests for decimal comparisons in random_decimal32_comp.cpp seem to be only testing decimals created from integer values (no fractions). I know that other Boost candidate libraries pass with fewer tests, but I feel this one needs to have a lot of them. I am not even sure how one tests user-defined literals across the spectrum. Maybe the unit tests should be written outside of C++. One can see that a lot of work went into preparing the documentation. It is helpful and already provides a lot of useful information, also about the background, and ideas. It has the "Design Rationale" section which reminds me of the high quality documentation that the original Boost libraries used to have. But I still find it insufficient. The API reference for the key types, like `decimal32_t`, only lists the class members, but there is no detailed description for the behavior of these members. What are the preconditions of the Decimal's constructors? Is any combination of values considered invalid? Or is it nicely degrading to subnormals and infinities? I think the contract of the library (how the cohorts are treated in comparisons, if they are implementation detail, or are observable?) need to be spelled out more clearly. Again, Matt has been very responsive, and the documentation has improved a lot during the review period, and I know it will improve further. Regarding the design, it looks like it has been done by IEEE, so not much to review here. I only had a short glimpse at the implementation, so I cannot say much. One thing that I found surprising is that operator<=> is implemented in terms of operators <, > and ==. Operator <=> was designed for the class authors to go the opposite way: define operator <=> and you get all the others for free. So I wonder what was the reason for the current implementation. I do not feel comfortable giving an accept or reject recommendation. I clearly have a higher acceptance bar for this library than for any other I have seen reviewed in Boost, and this may appear unfair. Do I want to see this library in Boost? -- yes. It is useful, and IEEE seems to agree. Are the authors the right people to implement it? -- definitely! But I would feel more comfortable accepting it, if it went through another review iteration. Could this be considered a conditional acceptance? In the case of the test sieve issue I brought up, I do not think it is a question of writing more tests. It is more a question of designing an approach to testing that would give a guarantee of correctness. This is requesting a lot of work from the authors who already put a lot of effort to get the library where it is. It is huge (both the library and the effort)! Again, this cannot be overstated. Matt and Chris: you did great work! Thank you! I know that sooner or later we will be able to use Boost.Decimal from the official distribution. Also, thanks to John Maddock for managing the review. Regards, &rzej;

3 3

Master regression tests failing
by Tom Kent 12 Oct '25

12 Oct '25

There seems to be a problem on master with all tests failing. It results in this in the log: error: Unable to find file or target named error: '/var/boost/run/boost_root/libs/system/build//boost_system' error: referred to from project at error: '../libs/graph_parallel/test' error: could not resolve project reference '/var/boost/run/boost_root/libs/system/build' Tom

4 4

[charconv] Possible bug
by Gennaro Prota 10 Oct '25

10 Oct '25

Hi, the following program prints "1e-01". Furthermore, it prints "Error: 132" if I change `size` to 20. It prints the expected "0.1" if I change the two using declarations to use the standard facilities. Tested against the master branch, with MSVC 2022. Is this a bug in CharConv? #include "boost/charconv.hpp" #include <charconv> #include <iostream> int main() { // using std::to_chars; // using std::chars_format::general; using boost::charconv::to_chars; using boost::charconv::chars_format::general; int const size = 100; char buffer[ size ]; auto const r = to_chars( buffer, buffer + size, 0.1, general ); if ( r.ec != std::errc() ) { std::cerr << "Error: " << static_cast< int >( r.ec ) << std::endl; return 1; } *r.ptr = '\0'; std::cout << buffer << std::endl; } -- Gennaro Prota <https://prota.dev>

2 1

[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