Re: [boost] a safe integer library

Subject: Re: [boost] a safe integer library
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-12-10 13:47:48

On 10/12/2015 07:49, Robert Ramey wrote:
> Arithmetic operations in C++ are NOT guaranteed to yield a correct 
> mathematical result. This feature is inherited from the early days of 
> C. The behavior of int, unsigned int and others were designed to map 
> closely to the underlying hardware. Computer hardware implements these 
> types as a fixed number of bits. When the result of arithmetic 
> operations exceeds this number of bits, the result will not be 
> arithmetically correct.
>
> I have crafted a library to address this issue once and for all. You 
> can find out more about this by checking out the page for Safe 
> Numerics at the boost library incubator. www.blincubator.com
>
> I hereby request that this library be added to the boost review queue.
>

In case you haven't seen it, Multiprecision's cpp_int type has a very 
similar "checked" mode that adds similar safety.

> I've also made a proposal for the C++ Standards committee to include a 
> simplified version of this library as part of he C++ standard.
>
> You can see the proposal at 
> http://www.rrsd.com/software_development/safe_numerics/proposal.pdf
>

In:

"Performance will depend on the implementation and subject to the 
constraints above. This design will permit the usage of template 
meta-programming to eliminate runtime performance penalties in some 
cases. In the following example, there is no runtime penalty required to 
guarantee that incorrect results will never be generated."

The example that follows surely can overflow:

void f(safe<int8_t> i){
safe<int8_t> j;
j = i * i; // C++ promotion rules make overflow impossible!
std::cout << j;
}

OK so the temporary returned by i*i *may* not overflow (depending on the 
size of type int), but the assignment to j most certainly can - I would 
expect that to throw, and if not it drives a coach and horses right 
through the proposal IMO.

What happens with floating point types?  Can values overflow to infinity 
or is this trapped?  How about divide by zero or indeed zero/zero 
(NaN)?  What about underflow?

And finally, I think there needs to be good constexpr support - in fact 
that could be the killer feature that sets the library apart.

Finally your documents title is "Java Printing" which you may wish to 
correct ;)

Best, John.

And
And