Re: [boost] safe integer library -- the scope

Subject: Re: [boost] safe integer library -- the scope
From: Damian Vicino (damian.vicino_at_[hidden])
Date: 2015-12-11 18:22:23

> On Dec 11, 2015, at 11:11 PM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> 
> 3. The docs mention a possible extension for safe<float>. I do not know
> what that would mean. In the case of safe<int> I know what to expect: you
> trap when I try to build value greater than INT_MAX  or smaller than
> INT_MIN: nothing else could go wrong. But in case of float: do you trap
> when I want to store:
> 
> safe<float> ans = safe<float>(1.0) / safe<float>(3.0);
> 
> ?? 1/3 does not have an accurate representation in type float. But if you
> trap that, you will be throwing exceptions all the time. So is it only
> about overflow?

yes we do, and no we don’t…
In the case of safe<foat>, different scenarios lead to different requirements. 
For example, in some contexts overflow to infinite is ok, but rounding not. In others rounding is ok, but overflow and underflow not. In others Pole-errors are okay, but domain errors not… Etc… plenty of use-cases…
The approach we took (still experimenting on it) is delegating the responsibility of deciding the “safeness” requirements to the user, and enforce whatever the user requires.

Thus, the datatype receives 4 template parameters:
— The datatype to wrap (float, double…)
— The list of checks to enforce (no-rounding, no-overflow, no-underflow, safe-cast, …)
— The way to report a failure (exceptions, errors, abort, assert, report to log….)
— The casting policies (never-cast, safe-cast, ... ).

Some of the policies are mentioned here: 
http://sdavtaker.github.io/safefloat/doc/html/types.html <http://sdavtaker.github.io/safefloat/doc/html/types.html>

That documentation is a little old and the way we implemented things changed a lot. 
However, the list of things we are checking stayed pretty stable.