|
Boost : |
From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-01-18 16:21:40
On Sat, 18 Jan 2025 at 15:03, Ivan Matek <libbooze_at_[hidden]> wrote:
>
>
>
> On Thu, Jan 16, 2025 at 2:07â¯PM Matt Borland via Boost <boost_at_[hidden]> wrote:
>>
>>
>> The only update I found was https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html. I emailed Dietmar a while back to ask why it was never accepted, but I did not receive a response.
>
>
> I found this SO answer, quite informative:
>
> I happened to be at the meeting where IBM initially proposed the decimal types to WG14 and WG21. Their initial proposal was to provide them as native types, which is pretty much the only solution in C. However, WG21 wasn't entirely convinced and pointed out that C++ already has std::complex<> as a mathematical type in the library, so why not std::decimal<>? Initial confusion about the performance overhead was quickly ended when it was pointer out that std::decimal could obviously wrap a _Decimal compiler extension.
>
> After poiting out that this could be done in a library, the next question was then whether this should be in the Standard library. It's after all a specialized domain in which this is useful. The most commonly though-of domain, finance, doesn't actually need it (they really need decimal fixed-point, not decimal floating point). IBM didn't push their proposal a lot further, after this feedback.
Actually, MySQL DECIMAL is fixed-point, not floating-point [1]. You
can select the precision using DECIMAL(p, s), where p is the precision
(between 1 and 65) and s is the scale (number of decimals). I'm
assuming that, as long as p <= the precision for the corresponding
Boost.Decimal type, things will work fine. For instance, decimal32
would be interoperable with DECIMAL(7) and less precise, and so on.
Is my assumption correct? Are there any caveats I should be aware of?
Thanks,
Ruben.
[1] https://dev.mysql.com/doc/refman/8.4/en/precision-math-decimal-characteristics.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk