> It's also not unusual to start with "x" statically initialized to zero,
> and use that as an indication to invoke the initialization routine.
This is exactly what I have. In my case, if the value remains 0.0 it
means the calculations for those metrics are not applicable.
The suggestion to use booleans and checking for Inf and NaN, would make
the code hard to read and maintain. Specifically:
1) Debugging "result = a / ((b + c) / d)" when d is 0.0 and the result
ends up being 0.0 is somewhat tedious. Here Inf due to division by 0.0
is lost in a complex equation. Either you have to break up the equation
and test each part for Inf/NaN or use fetestexcept().
2) I normally enable SIGFPE to catch issues like this very early, e.g.
(void)feenableexcept(FE_ALL_EXCEPT & (~FE_INEXACT));
Generating floating point exceptions would simply crash the program
with the default signal handler. The assumption is that such exceptions
are bugs in the code and not the default behavior.
The only issue is that some hardware does not support traps on floating
point exceptions. Hence, the fallback would be
bitmask = fetestexcept(FE_ALL_EXCEPT & (~FE_INEXACT));
if (bitmask != 0)
{
/* Test and report each exception to stderr */
}
before exiting main() function.
It is a bit unfortunate that the default behavior with many C compilers
is to ignore floating point exceptions.
