- Boost - lists.boost.org

[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