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 2007-03-18 14:26, Ev********@googlemail.com wrote:

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.

In general floating point errors do not throw exceptions in C++, for example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app). If you
want to handle floating point errors in C++ you have to check for them
yourself and throw an appropriate exception. One way tho do this is to
encapsulate float/double in a class with the same interface as dloat/
double but which performs those checks.

--
Erik Wikström

[jacekfoo]

On Mar 18, 3:24 pm, Erik Wikström <[e-mail]:

In general floating point errors do not throw exceptions in C++, for example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app).

Isn't it undefined behaviour? On my gcc it does only result in having
NaN that prints #INF when cout-ed.

[EvilOldGit]

On 18 Mar, 14:24, Erik Wikström <[e-mail]:

On 2007-03-18 14:26, [e-mail] wrote:

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.

In general floating point errors do not throw exceptions in C++, for example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app). If you
want to handle floating point errors in C++ you have to check for them
yourself and throw an appropriate exception. One way tho do this is to
encapsulate float/double in a class with the same interface as dloat/
double but which performs those checks.

--
Erik Wikström

I'm using VC++, and if you set the flags, it will throw an exception
on div/0 et al.
I've always done what Erik suggests, using test & throw, but have long
felt I could do a lot better.
I *nearly* have.
VC++ will throw a proper C++ style exception (not a Win32 SEH one)
But I ca'nt catch it.
If I could determine the type of exception I could then drill down
better.

My goal is to build a framework exceptionally bullet proof FP code,
that allows you to hunt down bugs with some precision.
I'm part way there, but have hit a wall.

[P.J. Plauger]

<ja******@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...

On Mar 18, 3:24 pm, Erik Wikström <[e-mail]:

In general floating point errors do not throw exceptions in C++, for
example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app).

Isn't it undefined behaviour? On my gcc it does only result in having
NaN that prints #INF when cout-ed.

Actually, it's an infinity that prints #INF. Dividing by zero is
indeed undefined behavior in Standard C or Standard C++. IEEE 754,
however, defines 1/0 as producing Inf with no need to trap unless
certain bits in the FPP demand it. So it's also permissible, both
under IEEE 754 or other floating-point systems, to terminate the
program.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Adrian Hawryluk]

Ev********@googlemail.com wrote:

On 18 Mar, 14:24, Erik Wikström <[e-mail]:

>On 2007-03-18 14:26, [e-mail] wrote:

>>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.

In general floating point errors do not throw exceptions in C++, for example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app). If you
want to handle floating point errors in C++ you have to check for them
yourself and throw an appropriate exception. One way tho do this is to
encapsulate float/double in a class with the same interface as dloat/
double but which performs those checks.

--
Erik Wikström

I'm using VC++, and if you set the flags, it will throw an exception
on div/0 et al.
I've always done what Erik suggests, using test & throw, but have long
felt I could do a lot better.
I *nearly* have.
VC++ will throw a proper C++ style exception (not a Win32 SEH one)
But I ca'nt catch it.
If I could determine the type of exception I could then drill down
better.

My goal is to build a framework exceptionally bullet proof FP code,
that allows you to hunt down bugs with some precision.
I'm part way there, but have hit a wall.

IIRC, when I did something like you are proposing, it required that I
made the exception class myself and somehow (its been a long time) hook
into the SEH to throw the exception myself. That was under VC++ 6.0.

You may want to try a newsgroup that specialises in MS VC++. This group
is for ANSI C++ language discussions.
Adrian
--
__________________________________________________ ___________________
\/Adrian_Hawryluk BSc. - Specialties: UML, OOPD, Real-Time Systems\/
\ My newsgroup writings are licensed under the Creative Commons /
\ Attribution-Noncommercial-Share Alike 3.0 License /
\_____[http://creativecommons.org/licenses/...sa/3.0/]_____/
\/______[blog:__http://adrians-musings.blogspot.com/]______\/

[EvilOldGit]

On 18 Mar, 16:09, "P.J. Plauger" <[e-mail]:

<[e-mail] in message

news:11**********************@n59g2000hsh.googlegr oups.com...

On Mar 18, 3:24 pm, Erik Wikström <[e-mail]:

In general floating point errors do not throw exceptions in C++, for
example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app).

Isn't it undefined behaviour? On my gcc it does only result in having
NaN that prints #INF when cout-ed.

Actually, it's an infinity that prints #INF. Dividing by zero is
indeed undefined behavior in Standard C or Standard C++. IEEE 754,
however, defines 1/0 as producing Inf with no need to trap unless
certain bits in the FPP demand it. So it's also permissible, both
under IEEE 754 or other floating-point systems, to terminate the
program.

P.J. Plauger
Dinkumware, Ltd.http://www.dinkumware.com

I see that it's permissible, but obviously not compulsory.
I'm trying to catch over/underflows and it's a bit painful.

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-03-18 16:44, Ev********@googlemail.com wrote:

On 18 Mar, 14:24, Erik Wikström <[e-mail]:

>On 2007-03-18 14:26, [e-mail] wrote:

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.

In general floating point errors do not throw exceptions in C++, for example

double i = 0;
double j = 1/i;

will not throw an exception (it will however terminate your app). If you
want to handle floating point errors in C++ you have to check for them
yourself and throw an appropriate exception. One way tho do this is to
encapsulate float/double in a class with the same interface as dloat/
double but which performs those checks.

--
Erik Wikström

I'm using VC++, and if you set the flags, it will throw an exception
on div/0 et al.
I've always done what Erik suggests, using test & throw, but have long
felt I could do a lot better.
I *nearly* have.
VC++ will throw a proper C++ style exception (not a Win32 SEH one)
But I ca'nt catch it.
If I could determine the type of exception I could then drill down
better.

Leaving the land of standardized C++ behind... It does not say in the
documentation of VC? An alternative, while not exactly what you want,
but couldn't you just

try {
/* FP OP */
}
catch (...) {
throw MyFPException;
}

This works if you can enclose the possible throwing FP operations with
try but at the same time be sure that no other exception can be thrown
in that section.

--
Erik Wikström

[jacekfoo]

On Mar 18, 4:44 pm, [e-mail] wrote:

My goal is to build a framework exceptionally bullet proof FP code,
that allows you to hunt down bugs with some precision.
I'm part way there, but have hit a wall.

Have you considered performance issues? Because in almost every
serious computation performance is a key parameter.

And also as I have learnt the hard way* some bugs just emerge from
rounding errors. So keep an eye for that too.

* After debugging the whole night I discovered that after swithing all
my templates to double my programs starts to give reasonable
resultus.

[EvilOldGit]

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 ?
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 ?

I've read the MS documentation, and whereas each part seems to be
true, it's lots of little bits. Thus you will get code that requires
very precise setting of barely documented parameters.
Don't appreciate docs of the form
"sets the <term not definedto <term not definedstate if you are
running on <obsolete processorbut this is deprecated you should use
<completely undocumented featureto do something subtly different
that we can't be bothered to tel lyou about. The GCC stuff seems as
bad, indeed it reads susprisingly like the MS docs, like the same evil
genous did both :(

I keep thinking that I'm being tragically stupid here. A large % of
all the FP work in the world is done in C++, it's not like I'm pushing
back the boundaries here.

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

On 19 Mar, 19:10, [e-mail] 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" <[e-mail]:

On 19 Mar, 19:10, [e-mail] 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, "[e-mail]"
<[e-mail]:

On 20 Mar, 07:52, "Erik Wikström" <[e-mail]:

On 19 Mar, 19:10, [e-mail] 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