Re: [boost] a safe integer library

Subject: Re: [boost] a safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-12-17 03:12:24

On 12/16/15 11:16 PM, David Stone wrote:
> I have written a similar library (http://doublewise.net/c++/bounded/), and
> I have a few questions about your implementation.

I'm very aware of this.  I attended your excellent presentation of you 
bounded integer library at C++Now 2014.  I've also referenced your 
library in the documentation for safe_numeric.  I was working on the 
safe numeric library at the time so that's why I was interested.
>
> You have a few policies for what to do on overflow. In particular, I see
> you have throw_exception and trap_exception. trap_exception provides a
> compile-time error instead of a run-time error. Could you explain this a
> little bit more?

As we speak I'm putting the final touches on this.  Basically it traps 
at compile time if an exception might occur.  That is if it cannot be 
known at compile time the the operation cannot fail - a compile time 
error is invoked.

> In my library, conversions for which the type is definitely in range (for
> instance, [1, 6] assigned to [0, 10]) are implicit and no check is
> performed.

this is similar

> Conversions for which the type is possibly in range are explicit
> and the policy is applied (run-time check).

hard to tell, but might be similar.

> Conversions for which the type
> is definitely out of range are a compile-time error,

In my case this is always an error.

> unless the overflow
> policy says that overflow is not an error.

But one could specify his own custom policy which ignored such an error. 
BUT I'm not sure how useful it would be as it would apply to the type - 
not the value so it would be hard to use as one might intend.

I do have a policy to ignore errors.  But I haven't tested it.  I'm 
thinking I should eliminate it as it would defeat the whole purpose of 
the library.

> Your overflow policies all seem to assume overflow is error.

It's not so much the policies - it's more my vision for the library 
usage.  The driving purpose is to be able to know that one's code 
implements correct arithmetic.  So my basic premise is that an overflow 
is an error.

> How difficult
> would it be to add in the ability to provide 'clamping' or 'saturation'
> behavior? If you go below the min, set the value to the min, and if you go
> above the max, set to the max.

I never considered this, and from what I know about the design of the 
library, I don't think it would be practical to implement on top of what 
I have now.

> Similar question for a modulo policy, which
> gives you the same behavior as unsigned integers.

I've got a whole different view of this as well.  Consider handing some 
other type - be it a wall known arithmetic type such as modulo integers 
or some special type like money.  My approach would be:

a) make your class - say a clock (modulo 60) or money class

b) declare safe<money> and you'll be done!

right - not quite.  But not that far off.  I have a couple of "back 
ends" which handle compile time integer<T> for any T and checked 
arithmetic which is templated on T.  Currently it works only for integer 
types. So one would have to specialize on checked<money> which would be 
defined in terms of checked<T> since money would be defined in terms of 
some integer.

As far as exceptions and promotions - selection of these would be 
independent of any particular type.

> I will have more thoughts later as I read the rest of the documentation.

I'm currently putting the finishing touches on an upgrade of the code 
and improvement and enhancement of the documentation.  The main 
enhancement will be a treatment of how to guarantee no errors with no 
runtime overhead.

I expect to have a new version by monday.

Robert Ramey