Boost logo

Boost :

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 (, 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at