Re: [boost] Decimal: Formal review begins.

  >>> Question:>>> I've noticed that this:>>>>>> 1.23456789098787237982792742932938492382342382342002934932_df>>> Compiles, although it truncates the>>> value to 1.234568. Would it make>>> sense to somehow tell the user "hey,>>> this literal is too long"

> Example about compile-time throw> message indication
> In a similar spirit to what fmtlib> does to error at compile time when> you make a mistake with format arguments.
> Of course, this requires a bunch> of ifdefs to make it work in C++14.
I think we have all those idiomswithin a C++-14-constexpr context.So we would just need to collectthem.
> So if you think it doesn't add> enough value, I understand it.
I was just thinking to myself,prior to reading this post,hey, wouldn't it make more senseif we catch this at compilet-time?
Now I'm liking this idea.
If we end up doing it or somethinglike it, why would we throw()instead of static_assert-ing it?Wouldn't static_assert be better?
- Chris


    On Friday, January 17, 2025 at 11:04:48 PM GMT+1, Ruben Perez  wrote:  
 
 On Fri, 17 Jan 2025 at 22:57, Christopher Kormanyos via Boost
 wrote:
>
>  >>> Question:>>> I've noticed that this:>>>>>> 1.23456789098787237982792742932938492382342382342002934932_df>>> Compiles, although it truncates the>>> value to 1.234568. Would it make>>> sense to somehow tell the user "hey,>>> this literal is too long"
> >> It would absolutely make sense,>> but then you would need the same thing>> to happen for float, double and>> long double in the Standard, which>> isn't going to happen.>> So Decimal follows suit.
> > That's not the same. Base 2 floats> don't need a fixed number of decimal> digits to be represented unambiguously,> but decimal floats do.
> Oh that's a good point. It goesinto the direction of languagespecification.
> When we talk about adding valueto this library today, we couldhave the discussion. I guesswe would need to figure out a portableway to provide such compile-time info.
> This might seem a bit skeptical frommy side, but, as much as I agree,I don't feel that it really leadsanywhere in the case of DecimalTODAY.
> I don't believe it's within the scopeor purpose of Decimal to figureout how to inform the client"Hey, your fixed-point representationjust walked off its digits".
> That would be something for theStandard, and perhaps evensomething for fixed-point ingeneral.

I was thinking of something along the lines:

BOOST_DECIMAL_EXPORT consteval auto operator ""_dd(const char* str,
std::size_t) -> decimal64
{
    decimal64 d;
    bool has_precision_error =
detail::from_chars_report_loss_of_precision(str, str +
detail::strlen(str), d);
    if (has_precision_error) throw std::runtime_error(); // throwing
in a consteval function just yields a compile time error
    return d;
}

In a similar spirit to what fmtlib does to error at compile time when
you make a mistake with format arguments.

Of course, this requires a bunch of ifdefs to make it work in C++14.

So if you think it doesn't add enough value, I understand it.

Regards,
Ruben.