Re: [boost] a safe integer library

Subject: Re: [boost] a safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-12-10 14:18:30

On 12/10/15 10:47 AM, John Maddock wrote:

> 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

correct, I'll fix this example

  - I would expect that to throw,

it will

> and if not it drives a coach and horses right through the proposal IMO.

agreed.  All binary operators are overloaded - including assigment.

> 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?

currently only integer types are addressed.  Damion Vicino has take on 
task of extending the library to floating point types.  He is a post 
doctoral student at INRIA and I believe he is well suited to the task. 
Turns out that implementing "safe" functionality for floating point 
numbers has a completely different set of issues and considerations. 
I'm sure this is not news to you.  it's almost a separate library.  He 
worked on this as a Google Summer of Code project.  If you want to lend 
a hand to him this, I'm sure it would be appreciated - and, very, very, 
valuable.

BTW - Since I have a (fatal) tendency to think big, I named the library 
Safe Numerics rather than Safe Integer.  But I think the safe integer is 
very useful in it's own right.

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

The implementation contains a module which does compile time range 
arithmetic which is all constexpr.  Before exploiting this, I was stuck 
- now I'm free.  BTW - the library (www.blincubator.com version) 
requires gcc 6.0+ in order to compile - due to constexpr problems in 
previous gcc compilers - I don't know about msvc.

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

What does it take to get a break here?

Robert Ramey