On Dec 11, 2015, at 11:11 PM, Andrzej Krzemienski
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.