Re: Decimal: Formal review begins.

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-01-16 14:36:46

On Thu, 16 Jan 2025 at 14:06, Matt Borland <matt_at_[hidden]> wrote:
>
>
> > What is the status of the DTR? It looks to be dated from 2009. Is it
> > realistic to think it will get into std at some point?
> >
>
> > Thanks,
> > Ruben.
>
> 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.
>
> Do I think decimal numbers should be in the standard? Yes, they're a type specified by IEEE 754 since 2008. SG6 has decimal floating point listed in their blurb of focus areas on the ISO Cpp website. It would be an uphill battle because Chris and I are outsiders to the committee, and this would be a huge proposal that touches a large percentage of the standard library. It would then take many years to get implemented. Last I checked libc++ still does not support C++17 math special functions and this would add to that. Chris and I said we would revisit talks on whether or not this is worth the effort once it's been accepted in boost, because then we at least have the reference implementation in hand.

Thanks. I'm trying to understand whether sticking to the TR has enough
value. If it doesn't, maybe we could consider applying Peter's
comments about making decimal32 be the fast one, or dropping sprintf.

Some more questions:
1. As a user, when should I pick decimal64 vs decimal64_fast? I intend
to implement support for your decimal types in the static interface of
Boost.MySQL as part of this review - should I support decimalXY,
decimalXY_fast, or both?
2. Is there a rationale behind only supporting the convenience header,
as stated in the docs? Including the entire library in my machine
(gcc-12, Ubuntu 22.04, -std=c++23) is about 4.5seconds - similar to
the entire Asio in magnitude. Including only decimal32.hpp cuts the
time to around 1s.
3. In the line of the previous question, is there a reason to have
BOOST_DECIMAL_DISABLE_IOSTREAM instead of splitting iostream
functionality to a separate header? In my experience, the more config
macros you have, the more chances of getting bugs. Also, is the test
suite being run with these macros defined?
4. From sprintf's documentation: "In the interest of safety sprintf
simply calls snprintf with buf_size equal to sizeof(buffer). ". This
doesn't look right. This is what the implementation looks like:

template <typename... T>
inline auto sprintf(char* buffer, const char* format, T... values) noexcept
    #ifndef BOOST_DECIMAL_HAS_CONCEPTS
    -> std::enable_if_t<detail::is_decimal_floating_point_v<std::common_type_t<T...>>,
int>
    #else
    -> int requires
detail::is_decimal_floating_point_v<std::common_type_t<T...>>
    #endif
{
    return detail::snprintf_impl(buffer, sizeof(buffer), format, values...);
}

If I'm reading this correctly, this is calling snprintf_impl with the
sizeof a pointer, which is probably not what we want. You'd need to
template the function on the buffer size and take a char array
reference to make this secure.

Regards,
Ruben.

>
> Matt