Re: Decimal: Formal review begins.

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-01-20 14:43:55

>
>
> > 2. For each decimal size, there's two types: decimal32 is the storage
> > optimized one, and decimal32_fast is the operation-optimized one. Like
> > Peter, I'm not convinced that making the storage optimized be the
> > default one is adequate. I understand that this is what the TR states,
> > though. I'd advise to consider Peter's suggestions [1] [2]. I don't
> > have enough field experience to know whether this is sufficiently
> > relevant, though. In any case, the documentation should state when to
> > use the standard ones vs the fast ones.
> >
>
>
> In this case it is the naming scheme provided by IEEE-754, which I think
> we would be remiss to ignore. I think the suggestion from Peter (and you
> below in bullet 3) to add implicit lossless conversions is good. <stdfloat>
> has far stricter rules than builtin floating point types but allows
> promotion up implicitly, but errors on shortening.
>

That's fair.

> > If you're not going to support all standard type specifiers, I'd think
> > of exposing a std::format-like function that works in C++14. Something
> > like decimal::format_decimal and decimal::print_decimal. This is just
> > a suggestion, though. I understand that, if this is pushed to the
> > standard, having these functions might be valuable.
> >

>
>
> The implementations of those functions was more in the realm of reference
> for how you would add the functionality to the existing STL should they be
> standardized. Making a complete working reimplementation of all those clib
> functions would be a huge undertaking for little benefit.
>
>
> Since <charconv> is available at C++14 doesn't that generally cover what
> format_decimal, and print_decimal would do? I specifically avoided using
> the STL here because requiring C++17 for a two member struct and an four
> member enum seemed silly.

Yes, that's fair, too. Charconv should be enough.

>
> > 9. Is boost::decimal::to_string public? It's handy, and in the public
> > namespace, but in a detail/ header and not documented. I'd advise to
> > make it public by moving the header to boost/decimal/ and documenting
> > it.
> >

>
>
> I'll move it. I think it goes along with your printing point, and is
> generally something I would expect to be provided for a numeric type.

I discovered it through the IDE and I think it's a useful thing. I think
this is the right thing to do.

Thanks,
Ruben.