Re: [boost] a safe integer library

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 i){ safe 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