2018-06-18 22:31 GMT+02:00 Damian Vicino via Boost <boost@lists.boost.org>:
Hi Jeff, Thanks for the comment, I will definitely work in a good answer and add the question to the FAQ in the manual.
In general, the main differences I see are: - Flexibility and more granular control: FPE is for all or nothing, while safefloat can be used to enforce some checks for a subgroup of all the floating point variables in the program or library. Also, safe_float may provide different checks in different contexts, not an all or nothing flag. - More options on how to react to failure. FPE will abort, while safefloat library provides different strategies to act when a check fails, it may be the case that you can expect a check to fail under certain conditions (exceptional behavior). An alternative would be to manually check flags after each operation, in place of doing that, safe float could throw an exception that can be handled, or return an unexpected_value that can be also handled. - Multiplatform/compiler: safe_float is suppose to work in any compiler implementing the c++ standard.
A real use case I had was that I wanted to capture the check failures in logs but not failing in the wild (given service was running without check for long time). I added safe_float with the "on_fail_cerr" policy, and that provided some valuable insights in logs attached to bug reports. At the time, we already diagnosed the bug and this only added more data to support the bug, but having safe float before start could allow us to catch the bug long time before.
Does this make sense?
It makes sense for me. Again, this explanation is worth adding in the docs under a section like "why use this library rather than what we already have". Regards, &rzej;
Best regards, Damian
2018-06-18 14:02 GMT-04:00 Jeff Hammond <jeff.science@gmail.com>:
Maybe I am dense, but what is the difference between this and what I can get from e.g. the Intel compiler by enabling FPEs?
Thanks,
Jeff
-fp-trap=<arg>[,<arg>,...]
control floating point traps at program start. <arg> can be of the
following values
[no]divzero - [Do not] trap on division by zero
[no]inexact - [Do not] trap on inexact result
[no]invalid - [Do not] trap on invalid operation
[no]overflow - [Do not] trap on overflow
[no]underflow - [Do not] trap on underflow
[no]denormal - [Do not] trap on denormal
all - enable trap on all of the above
none - trap on none of the above
common - trap on most commonly used IEEE traps
(invalid, division by zero, overflow)
On Sun, Jun 17, 2018 at 8:53 PM, Damian Vicino via Boost < boost@lists.boost.org> wrote:
Hi, I'm preparing my library safe_float to be proposed for review.
The library was born in the GSOC2015, but it never reached a review ready state. My plan is to change that in the next few months.
At this point, I'm looking for some volunteers to proof-read the documentation. Code is going through major rewrite, and I will send another mail looking for help with reviewing the code when that is done.
The most current documentation can be read directly from the web here: https://sdavtaker.github.io/safefloat/
Any comment is appreciated.
Best regards, Damian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
-- Jeff Hammond jeff.science@gmail.com http://jeffhammond.github.io/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost