
Joaquín M López Muñoz wrote:
No dia 15 de jan. de 2025, às 10:34, John Maddock via Boost
escreveu: The review of the proposed Decimal Number library by Matt Borland and Chris Kormanyos begins today and runs until 22nd Jan.
You will find documentation here: https://cppalliance.org/decimal/decimal.html
A small typo I spotted: s/convince header/convenience header
Some quick comments from me as well: "The final number constructed is in the form (sign || coeff < 0 ? -1 : 1) x abs(coeff) x 10^exp." This doesn't make much sense formatting-wise; the "(sign || coeff < 0 ? -1 : 1) x abs(coeff) x 10^exp" part should be formatted differently and not mix code and ad-hoc 'x' multiplication notations. namespace boost { namespace decimal { // Paragraph numbers are from ISO/IEC DTR 24733 // 3.2.2.1 construct/copy/destroy constexpr decimal32() noexcept = default; This doesn't compile. "class decimal32 {" is missing. The default "decimal32" name is occupied by the storage-optimized form and not by the operation-optimized form. I don't think this is the right decision. The storage-optimized form should only exist in memory, and everything else should use the operation-optimized form. E.g. if we have (illustrative) decimal32 f( decimal32 a, decimal32 b ) { return a+b; } decimal32 g( decimal32 a, decimal32 b ) { return a*b; } int main() { decimal32 a, b, c, d, e; e = f( g(a, b), g(c, d) ); } this currently would do a few unnecessary packs and unpacks. But if f/g take and return the operation-optimized form, these unnecessary pack+unpack operations are avoided. That is, if "decimal32" is the operation-optimized form, and we have e.g. "decimal32bid" for the BID encoded form, main would be int main() { decimal32bid a, b, c, d, e; e = f( g(a, b), f(c, d) ); } So the actual storage ("at rest") is still the same, but operations are more efficient. Note that in this case decimal32bid has no operations, only conversions from and to decimal32. The actual arithmetic is always performed over the operation-optimized form.