On 19 Mar, 19:10, EvilOld...@googlemail.com wrote:
I'm trying to do diagnositcs on broken floating point code, hence I
don't care about speed, but care a lot about it not dying.
Erik has recaptured my point that I've reached. I can catch FP
exceptions, but can't work out their class and am forced to use
catch(...)
I'm doing it in (spite of) VC++ but I came to this thread because I
was hoping that standard C++ might have a standard way of handing FP
exceptions.
If this isn't part of the C++ standard, why not ?
Nope, not as exceptions at least. It looks like you can determine the
type of FP exception (at least to some degree) using SEH.
I accept that at the lower level it's processor and O/S dependant, but
isn't the point of a standardised high(ish) language that I can write
platform independant code ?
If you want true platform independence you can only standardize the
common subset of all platforms, so if not all platforms support a
certain action then you can not include it unless it can be emulated.
I would suspect that FP exceptions were one of those things that were
not supported on all platforms.
Another problem with FP exceptions is that they are often asynchronous
in the sense that due to optimizations and other stuff you have
already started to execute one or more other statements when the
exception arises. What if you are executing two FP ops and one of them
raises an exception, how to tell which caused the exception, remember
that they can also have been rearranged by the CPU before execution.
--
Erik Wikstr=F6m