What is the class of a loating point exception ?

[EvilOldGit]

In Stroustrup he talks of a MathErr class that you can use to catch
floating point exceptions.
It doesn't exist, at least not in Visual C++

I can catch FP exceptions using catch(...) but am stumped in finding
out what the class I'm catching is.
I would like to know how to catch them in a more elegant way than
catch(...) and then poling around in registers to guess the problem.

TIA
EoG

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 19 Mar, 19:10, EvilOld...@goog lemail.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öm

[dominic.connor]

On 20 Mar, 07:52, "Erik Wikström" <eri...@student .chalmers.sewro te:

On 19 Mar, 19:10, EvilOld...@goog lemail.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öm

Although FP exceptions are asychronous, is it not the case that
processors have the equivalent of the Intel fwait, which synchronises
them ?

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 20 Mar, 09:43, "dominic.con... @gmail.com"
<dominic.con... @gmail.comwrote :

On 20 Mar, 07:52, "Erik Wikström" <eri...@student .chalmers.sewro te:

On 19 Mar, 19:10, EvilOld...@goog lemail.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öm

Although FP exceptions are asychronous, is it not the case that
processors have the equivalent of the Intel fwait, which synchronises
them ?

Don't know, but I bet that some processors for embedded systems don't.

--
Erik Wikström