whbloodworth@usa.net (William H. Bloodworth) wrote:
>>And the C standard requires a certtain minimal capability in this area,
>>which permits even wider portability.
>>
>>So, in fact, as it stands, handling these as signals is actually more
>>portable than handling them as "structured exceptions".
>
>Portable on *all* "Unix" platforms...is still not portable (by definition).

You missed the last sentence: to be conforming to the C standard, even
Windows and Mac implementations must support signals.

However, there is also the fact that "structured exceptions" are a
VisualC/C++ specific extension, so are ipso facto *less* portable than
something available on all Unix systems.  After all, even other Windows
compilers lack this "feature".

The peace of God be with you.

Stanley Friesen


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37CC031F.AD7@wanadoo.fr>, Bonnard.V@wanadoo.fr says...
> Jerry Coffin wrote:
>
> > Second, structured exceptions have a
> > number of capabilities that simply aren't present in C++ exceptions as
> > they were standardized.  I believe MS argued in favor of including
> > more of those capabilities during the standardization process, but the
> > arguments were considered unconvincing, so they weren't included.
>
> Which capabillities ?

Resumption is the primary capability I was talking about.  The other
obvious one is the ability to specify a "finally".  In C++, this can
normally be handled reasonably well by placing "finally" type things
in destructors, but sometimes you end up needing to create objects
primarily (if not exclusively) to ensure that something gets executed
in the dtor.

IMO, finally clauses are useful primarily as a transition.  Exception
safety is fairly easy to handle in new code, by initializing things in
ctors and cleaning up in dtors.  Unfortunately, if you have a large
body of C code (for example) making it exception safe at the present
time often requires a total rewrite into classes, so there will be
dtors to clean things up as needed.  Otherwise, you can put in try
blocks around things that might cause exceptions, and add in catch
blocks to clean up afterwards.  In most cases, you've got a fairly
specific set of actions that _always_ have to be executed on exit,
regardless of why/how you're exiting.  In this case, a finally block
makes life simple: you wrap your cleanup code in a finally block, and
it always gets executed.  With careful use of catch() blocks, you can
normally do what you need, but in many cases, it becomes more
difficult, as well as often causing duplicated code for the normal
exit and the exception exit.

Resumable exceptions are a bit different situation.  I think they have
much greater long-term usefulness, and I really hope they'll become
portable.  I think it's unfortunate that they've been used mostly in
mainframes and passed directly from IBM down to MS, bypassing most of
the systems in-between.  It's even more unfortunately that many C++
vendors appear (at least to me) to view anything associated with
mainframes or MS with such distaste that the ideas are dismissed out
of hand.  Though I certainly don't want to start a flame-war about it
(and can see the possibility) I'm personally convinced that if
resumable exceptions had been advanced primarily by representatives
from, say, Sun and HP, that they'd now be in the standard.  As-is,
they not only aren't available presently, but I suspect there's little
chance that they'll ever be added either (since modifying the current
exceptions to include resumption looks to me like quite a difficult
undertaking, no matter how many people become convinced of their
utility).

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
>If division by zero calls a C signal, and doesn't abort the program, then it
>must also produce some numeric result so that the calculation can continue. It
>would seem to me that signals are an inferior way of doing something that is
>better accomplished with NaNs.

Compared to NaNs, yes,signals are inferior.  I thought I was comparing
to C++ Exceptions.

But I am not sure your reasoning is quite correct in regards to the
necessity of producing a numeric result.  As far as I know, that is left
to the signal handler to deal with if it is to attempt resumption (as
opposed to termination).

The peace of God be with you.

Stanley Friesen
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> It's very deplorable that standard delegates details of handling such
> situations to the compiler. It's quite obvious that you can't live
> with "core dump" that gcc offers, or your customers stop buying your
> products.

On Unix, division by zero generates a SIGFPE (or something similar).
Why not use the standard signal() to catch it?

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
>
> The second is the finally block, which I believe is to be found in Java.
> Code in the finally block is executed whether the "try" code throws an
> exception or not.

I think this is in Java primarily _because_ Java doesn't have destructors that
are called when objects go out of scope.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stanley Friesen wrote:
>
> However, there is also the fact that "structured exceptions" are a
> VisualC/C++ specific extension, so are ipso facto *less* portable than
> something available on all Unix systems.

Structured exceptions are a feature of the Win32 operating system, not
of any particular language or compiler. Borland's C++ and Pascal
compilers support them.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William H. Bloodworth" wrote:

> On 31 Aug 1999 17:17:31 GMT, stanley@West.Sun.COM (Stanley Friesen
> [Contractor]) wrote:
>
> >
> >So, in fact, as it stands, handling these as signals is actually more
> >portable than handling them as "structured exceptions".
>
> Portable on *all* "Unix" platforms...is still not portable (by definition).
>

Although UNIX is not the only platform to have signals either. (Win32 for
example has them also)

Nick
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:

> Jerry Coffin wrote:
>
> > Second, structured exceptions have a
> > number of capabilities that simply aren't present in C++ exceptions as
> > they were standardized.  I believe MS argued in favor of including
> > more of those capabilities during the standardization process, but the
> > arguments were considered unconvincing, so they weren't included.
>
> Which capabillities ?

I believe you can actually access (and change) the current CPU context
(including instruction pointer, registers etc.)
An example of this was given in Jeffry Richters Windows book i believe, where
he used this technique to demonstrate a memory allocator that only allocates
memory when a segfault occurs and "fixes up" the registers to use the new
memory. A little weird maybe, but there ya go.
(of course, he needed an #ifdef INTEL, #ifdef ALPHA in his code too ;)

Nick
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote in message <37CC031F.AD7@wanadoo.fr>...
>Jerry Coffin wrote:
>> Second, structured exceptions have a
>> number of capabilities that simply aren't present in C++ exceptions as
>> they were standardized.  I believe MS argued in favor of including
>> more of those capabilities during the standardization process, but the
>> arguments were considered unconvincing, so they weren't included.
>
>Which capabillities ?

Based on the facilities offered by Windows, I expect there were two.

The first is resumption, whereby a caller can handle an error, patch it
up and ask that the processor "return from the throw" and carry on
where it left off. Not all exceptions are resumable. In D&E, it is argued
that this tends to blur layers of abstraction. One particular case is cited
where people whose OS supported resumption, and who themselves
liked the feature and used it for many years, eventually found that
bug fixes had systematically eliminated every use in favour of of a new
design. Except one. They removed it, and noted a small performance
improvement. Microsoft's own experience with OS/2 (which supports
resumption) was not considered to be a compelling demonstration of
the benefits. (Ouch!)

The second is the finally block, which I believe is to be found in Java.
Code in the finally block is executed whether the "try" code throws an
exception or not. Supporting "finally" makes it easier to ensure the
correct undoing of actions which haven't been wrapped in objects.
(People with legacy code which doesn't wrap its resources in objects
will also find it useful for releasing those resources.) The effect can be
obtained by defining a class with a destructor that does the required
clean up, but unless the compiler supports local classes with access
to variables on the stack frame, this can be very tedious to set up.

As you can guess from the above, I can live without resumption but
would rather like to see "finally", on the grounds that it supports
exception safety without forcing everything into the object paradigm.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Aug 1999 17:17:31 GMT, stanley@West.Sun.COM (Stanley Friesen
[Contractor]) wrote:

>>>When using gcc in a case where core dumps are unacceptible, I set up
>>>signal handlers for everything.
>>
>>Wouldn't that pretty much shoot portability in the proverbial foot?
>>
>Signal handling like this is portable to *all* Unix platforms.
>
>And the C standard requires a certtain minimal capability in this area,
>which permits even wider portability.
>
>So, in fact, as it stands, handling these as signals is actually more
>portable than handling them as "structured exceptions".

Portable on *all* "Unix" platforms...is still not portable (by definition).

W. Bloodworth

=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
=====================================================================



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Stanley Friesen [Contractor]" wrote:
>
> And gcc, which by default produces a core dump, *does* have such a way.
> It uses the Unix method of setting *signal* *handlers*, which even have
> the capability of providing resumption semantics, something one cannot
> do with C++ exceptions.

If division by zero calls a C signal, and doesn't abort the program, then it
must also produce some numeric result so that the calculation can continue. It
would seem to me that signals are an inferior way of doing something that is
better accomplished with NaNs.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote in message <0a8e94102211f89CPIMSSMTPE01@msn.com>...
>
>There are three possibilities.
>One, verify that parameters supplied to the expression are all correct
>and do not cause div by zero or similar problems. This is very bad
>approach.
>The second, verify that the result of expression is valid. And this has
>to be done in EVERY expression and then program must make
>corresponding decisions after EVERY expression. This is what
>exceptions were supposed to make unnecessary.
>The third, let the useless data propagate to the end. The whole program
>run is an overhead.
>Whatever approach you choose, it's inconvenience and overhead.
>In case of exception mechanism, you have an overhead only when div by 0
>occures and FP unit causes interrupt that throws exception, not otherwise.

I do not accept your second and third alternatives. There is a middle
ground, of checking when convenient.

Your first solution seems quite sensible. Apart from FP arithmetic,
I would hazard that all hardware traps indicate a program logic error
rather than a run-time error. Integer division by zero is like using a
pointer to a deleted object.

However, there is a saying to the effect that "when you are near a
singularity mathematically, you are at a singularity numerically" so I
accept that FP arithmetic is sometimes harder to control. The problem
for C and C++ (and any other language that exposes the full speed of
the processor) is that not all processors have the same facilities. Some
follow the IEEE standard. Some can trap exceptions synchronously.
Some can do both. Some can do neither, but have equally powerful
means at their disposal. As far as I am aware, no-one has ever wrapped
all the differences behind a library.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote in message <37C9299F.FB85178F@acm.org>...

>There are other views on the usefulness of NaNs. The whole point is that
>they propogate through the computation (I don't know of any situation
>where they "can be lost somewhere"), and that saves having to check
>every step along the way.

I minor correction.  Code like

  double max(double a, double b){ return a > b ? a : b; }

will probably not always propogate NaNs.

I'm no expert in this area.  I have come to the conclusion that there is no
simple silver bullet that is always the "correct" way to deal with floating
point errors.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0620e5145171e89CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
<gbush@my-deja.com> wrote:

> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-3008990257170001@aus-
> as3-068.io.com...
> [snip]
> > Who says divide by zero is caught without any performance overhead, and
> > that a C++ exception can be reliably thrown when this condition is
> > detected?
>
> Division by zero is detected on a processor level.

Or not.

> This is one of many
> operations when processor sets corresponding flag and causes interrupt only
> when this condition occures.

Did you forget that Intel isn't the only processor in existence again?!?

> There is no overhead otherwise.

Try this simple test:

    Divide this floating-point number by that floating-point number (this
takes a while)
    Set this memory location to 1 (quick operation)
    But... if the floating-point operation yields infinity, don't set the
memory location to 1.

You've got to stall the memory setting until you know the floating-point
operation won't give infinity, regardless of whether it actually yields
infinity. This is overhead.

> Using NaN or Infinity is a great overhead indeed with any scenario.

Actually, I'd say it's the other way around - NaN and Infinity could be
processed in parallel in the FP hardware without stalling anything (as far
as I can imagine - I don't know for sure).

> > How about just checking for zero before the divide? Seems pretty simple to
> > me.

> It's even worse than checking for Infinity after the whole calculation.

Yes it is, but if you have to know precisely where the infinity/NaN is
generated in the calculation, it would likely be more efficient than
relying on precise processor exceptions.

> This
> way you have to dismantle the expression verifying each part separately.

Well, yeah, *if* you (for whatever reason - would you like to provide
some?) have many operations that could independently generate
infinity/NaN, and you have to know exactly which one generated it.

> And
> don't forget floating point number doesn't have to be exactly 0 to produce
> Infinity.

Just check for infinity after the operation then.

> > > Division by zero is not the only error that must be standardized. The
> same
> > > situation is with over- and underflow, invalid operation, range check
> > > exceptions.
> >
> > Does most hardware that C++ runs on automatically do overflow and
> > underflow checks without any performance overhead, and allow one to trap
> > these and turn them (reliably) into a C++ exception?
>
> Same question as above. I can't imaging arithmetic processor as bad as not
> to be able handling such situations without penalty.

I'm having some trouble parsing that. Do you mean that you can't imagine a
processor not able to diagnose overflow and underflow without penalty? Can
you name a popular processor that does integer overflow/underflow checking
without any performance overhead as compared to non-checked operations?

> Division by zero is an exceptional situation that breaks the normal program
> flow. This is exactly what exceptions are for.

Uhhh, no. I suggest you get Stroustrup's Design and Evolution of C++ book
and read it.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-3008990257170001@aus-
> as3-068.io.com...
> [snip]
> > Who says divide by zero is caught without any performance overhead, and
> > that a C++ exception can be reliably thrown when this condition is
> > detected?
>
> Division by zero is detected on a processor level. This is one of many
> operations when processor sets corresponding flag and causes interrupt only
> when this condition occures. There is no overhead otherwise. Using NaN or
> Infinity is a great overhead indeed with any scenario.
>

NaN and Infinity are handled by the math coprocessor with no extra
overhead beyond that involved in the same operation with an ordinary
value.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Coffin wrote:

> Second, structured exceptions have a
> number of capabilities that simply aren't present in C++ exceptions as
> they were standardized.  I believe MS argued in favor of including
> more of those capabilities during the standardization process, but the
> arguments were considered unconvincing, so they weren't included.

Which capabillities ?

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-3008990257170001@aus-
> as3-068.io.com...
> [snip]
> > Who says divide by zero is caught without any performance overhead, and
> > that a C++ exception can be reliably thrown when this condition is
> > detected?
>
> Division by zero is detected on a processor level. This is one of many
> operations when processor sets corresponding flag and causes interrupt only
> when this condition occures. There is no overhead otherwise. Using NaN or
> Infinity is a great overhead indeed with any scenario.

NaN/Infinity is done at the processor level. The CPU (FPU) generates
it, just as it generates an 0.5, if you divide 1 by 2. Of course,
there may be a flag that causes an interrupt/processor exception
on NaN (as in x86), however, such an interrupt/PE is overhead
(the processor must save its current execution status, read the
interrupt table, possibly change privileg levels, and jump to
the new code - no prefetch possible, of course, and the code
is most probably not in cache, possibly even swapped out on disk.
So NaN/Infinity is more efficient here.

On processors without floating point support, you'll detect the
division by zero in your floating point code anyway, since
zero has a special representation. Therefore just producing
an Infinity or NaN (i.e. loading the register with a known
fixed value, and return) is more efficient again.

Do you know _any_ processor where interrupts are _not_
an overhead?
BTW, if C++ should throw an exception, you must add the
C++ exception overhead to the processor intrerrupt overhead.
And the C++ exception overhead is very high as well (probably
much higher than processor interrupt overhead).

[...]

> > > Division by zero is not the only error that must be standardized. The
> same
> > > situation is with over- and underflow, invalid operation, range check
> > > exceptions.
> >
> > Does most hardware that C++ runs on automatically do overflow and
> > underflow checks without any performance overhead, and allow one to trap
> > these and turn them (reliably) into a C++ exception?
> >
> Same question as above. I can't imaging arithmetic processor as bad as not
> to be able handling such situations without penalty.

Same as above. I cannot imagine a processor as good as to give
interrupts without noticeable overhead.
And about bounds checking: Since the processor doesn't know
_anything_ about your data structures, it cannot do automatic
bounds checking. It may have an instruction to do it cheap,
but not without cost (at least not in the general case;
in a specific case, it may cause no cost if it can be paired
with another instruction, where otherwise no pairing is possible)

>
> Division by zero is an exceptional situation that breaks the normal program
> flow. This is exactly what exceptions are for.

It would be nice to have the _option_ of having an exception thrown.
It would be bad to be _forced_ to have an exception thrown.

Processor exceptions/interrupts have overhead.
C++ exceptions have even more overhead.
NaNs are handled in the processor, and therefore don't cause
overhead at all (you might speculate if a processor not
supporting NaNs could be faster; however, given a processor
which does handle them, you surely don't get any improvement
by not using them).
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:

> Division by zero is an exceptional situation that breaks the normal program
> flow. This is exactly what exceptions are for.

Division by zero is an unchecked programming error,
which is _not_ what exeptions are for.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> There are three possibilities.
> One, verify that parameters supplied to the expression are all correct and
> do not cause div by zero or similar problems. This is very bad approach.
> The second, verify that the result of expression is valid. And this has to
> be done in EVERY expression and then program must make corresponding
> decisions after EVERY expression. This is what exceptions were supposed to
> make unnecessary.
> The third, let the useless data propagate to the end. The whole program run
> is an overhead.
> Whatever approach you choose, it's inconvenience and overhead.
> In case of exception mechanism, you have an overhead only when div by 0
> occures and FP unit causes interrupt that throws exception, not otherwise.

If arithmetic errors produce NaNs, the programmer can make an intelligent
choice of how often to check for them. In numeric applications, it's common to
have statements, or short sequences of statements, that have a dozen or so
operations. Checking for a NaN after such a sequence is pretty low-overhead,
with very little waste in the case of an error. It also provides a clean way
of detecting numeric errors without trying to accomplish the nightmare of
throwing a C++ exception automatically.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0025d3137021c89CPIMSSMTPE01@msn.com>, Gene Bushuyev
<gbush@my-deja.com> writes
>It's very deplorable that standard delegates details of handling such
>situations to the compiler. It's quite obvious that you can't live with
>"core dump" that gcc offers, or your customers stop buying your products.
>Borland, for example, to address this problem has more than 70 classes
>derived from a single class Exception. In real programs you must have the
>ability to catch all this different types of errors that standard defines as
>undefined behavior.

You mean that the C++ Standard should mandate that divide by zero will
throw an exception?  I would be very unhappy if it did.  Some systems
support NaNs and divide by zero should generate a NaN on such a system.

Of course there should be a mechanism for handling such things as divide
by zero but it should be left to an implementer to decide how and
document it.  In the case of 'divide by zero' I doubt that many
programmers would trap it anyway.  If you are writing robust, fault
tolerant, mission critical software you need suitable tools and gcc
clearly does not match this requirement (neither IMO does Visual C++)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
> Why the structured exceptions don't derive from
> std::logic_error is beyond me.

structured exceptions in MSVC are a C and C++ concept, not just a C++
concept, so that's why.  You can provide a mapping from structured
exceptions to std::logic_error, though, via _set_se_translator.

--
kevin kostrzewa
work: kkostrzewa@csisolutions.com
home: tkkost@newsguy.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
news:DuV1XmAWT9x3EweF@robinton.demon.co.uk...
> In article <0025d3137021c89CPIMSSMTPE01@msn.com>, Gene Bushuyev
> <gbush@my-deja.com> writes
> >It's very deplorable that standard delegates details of handling such
> >situations to the compiler. It's quite obvious that you can't live with
> >"core dump" that gcc offers, or your customers stop buying your products.
[snip]
> You mean that the C++ Standard should mandate that divide by zero will
> throw an exception?  I would be very unhappy if it did.  Some systems
> support NaNs and divide by zero should generate a NaN on such a system.
>
Yes, standard could mandate throwing exception when division by zero
happens. It's obviously exceptional situation and systems that offer NaNs
make a disservice to programmer. It's not feasible to verify NaN after each
arithmetic operation. If not caught that NaNs can be lost somewhere and get
erroneous results without user even knowing it. Even if they are not lost,
seeing NaN in the output doesn't give you much, only says about time spent
in vain. This is absolutely impractical approach.

> Of course there should be a mechanism for handling such things as divide
> by zero but it should be left to an implementer to decide how and
> document it.  In the case of 'divide by zero' I doubt that many

Why should it be left to an implementor to decide? BCB, for example, throws
EDivByZero exception and it's very convenient. Why can't standard specify
similar behavior? Divizion by zero is quite common error, why should the
program behave differently depending on the compiler?

> programmers would trap it anyway.  If you are writing robust, fault
> tolerant, mission critical software you need suitable tools and gcc
> clearly does not match this requirement (neither IMO does Visual C++)

Whatever software you may write, division by zero may happen. Out of bounds
input data, singular matrices, etc. may cause division by zero. Often
programmers wrap such code in try block and when exceptions caught notify
user about wrong input or modify calculations to avoid this error, or
whatever other actions may be necessary.
Division by zero is not the only error that must be standardized. The same
situation is with over- and underflow, invalid operation, range check
exceptions. There is nothing system specific in these errors that standard
may leave it to the discretion of the compiler vendor.

Gene Bushuyev




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Klein wrote:
>
> >> VC++ AFAIK generates a "structured exception", which is a
> >> Windows specific thing; C++ exceptions are just a special
> >> sort of structured exceptions, and catch(...) catches all
> >> structured exceptions (and therefore all C++ exceptions as
> >> well).
>
> Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> >Why the structured exceptions don't derive from
> >std::logic_error is beyond me.
>
> The VC++ documentation seems to imply that structured exceptions
> come from a time before VC++ supported (at least fully) C++
> exceptions. Like so many other things in VC++, they are the way
> they are for compatibility with old code.

Structured exceptions are part of the OS, and can be used from any
language. C++ exceptions fit fairly naturally on top of the structure
presented by the OS.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <DuV1XmAWT9x3EweF@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>Of course there should be a mechanism for handling such things as divide
>by zero but it should be left to an implementer to decide how and
>document it.  ...

And gcc, which by default produces a core dump, *does* have such a way.
It uses the Unix method of setting *signal* *handlers*, which even have
the capability of providing resumption semantics, something one cannot
do with C++ exceptions.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37CA6A99.4859B24@wizard.net>,
James Kuyper Jr. <kuyper@wizard.net> wrote:
>Robert J Macomber wrote:
>> In article <37C6C6DE.6A24@wanadoo.fr>,
>> Valentin Bonnard  <Bonnard.V@wanadoo.fr> wrote:
>....
>> >Why the structured exceptions don't derive from
>> >std::logic_error is beyond me.
>>
>> Because, as he said, *any* C++ exception is a structured exception (in
>> fact, there's nothing C++-specific about structured exceptions;
>> they're part of the Windows ABI).  In other words, std::logic_error
>> "derives" from this structured exception thing, if you want to look at
>> it that way.
>
>Since a structure exception is not a C++ class, std::logic_error cannot
>be derived from it, at least in the C++ sense. You can't say
>'catch(__structured_exception)', and that's the problem.

Yes; that's why I put "derives" in quotes - I wasn't meaning to say
that there's literally a structured exception base class, merely that
any C++ exception is a structured exception.  My intent was to make an
analogy to the "ISA" relationship that inheritance is often used to
model.
--
   Rob Macomber
    (rmacombe@u.arizona.edu)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <user-3008990246360001@aus-as3-068.io.com>,
blargg <postmast.root.admi.gov@iname.com> wrote:
>
>In article <0025d3137021c89CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
><gbush@my-deja.com> wrote:
>> ...
>> It's quite obvious that you can't live with
>> "core dump" that gcc offers, or your customers stop buying your products.
> ...
>
>Catch doesn't have to mean "catch"ing an exception. For example, signals
>provide a way to handle many low-level errors Unix-type operating systems.

Which in fact solves Gene's issue with gcc, as gcc supports this method.

When using gcc in a case where core dumps are unacceptible, I set up
signal handlers for everything.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-3008990257170001@aus-
as3-068.io.com...
[snip]
> Who says divide by zero is caught without any performance overhead, and
> that a C++ exception can be reliably thrown when this condition is
> detected?

Division by zero is detected on a processor level. This is one of many
operations when processor sets corresponding flag and causes interrupt only
when this condition occures. There is no overhead otherwise. Using NaN or
Infinity is a great overhead indeed with any scenario.

[snip]
>
> How about just checking for zero before the divide? Seems pretty simple to
me.
>
It's even worse than checking for Infinity after the whole calculation. This
way you have to dismantle the expression verifying each part separately. And
don't forget floating point number doesn't have to be exactly 0 to produce
Infinity.

> > Division by zero is not the only error that must be standardized. The
same
> > situation is with over- and underflow, invalid operation, range check
> > exceptions.
>
> Does most hardware that C++ runs on automatically do overflow and
> underflow checks without any performance overhead, and allow one to trap
> these and turn them (reliably) into a C++ exception?
>
Same question as above. I can't imaging arithmetic processor as bad as not
to be able handling such situations without penalty.

Division by zero is an exceptional situation that breaks the normal program
flow. This is exactly what exceptions are for.

Gene Bushuyev
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37c85983.344040954@news.videotron.ca>, bill@orbit.org
says...

[ ... ]

> The VC++ documentation seems to imply that structured exceptions
> come from a time before VC++ supported (at least fully) C++
> exceptions. Like so many other things in VC++, they are the way
> they are for compatibility with old code.

There's more to it than compatibility with old code: first of all,
structured exceptions are part of the OS, and can (and routinely are)
used from languages such as C and Pascal that don't support
"exceptions" as-such at all.  Second, structured exceptions have a
number of capabilities that simply aren't present in C++ exceptions as
they were standardized.  I believe MS argued in favor of including
more of those capabilities during the standardization process, but the
arguments were considered unconvincing, so they weren't included.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Aug 99 05:33:54 GMT, stanley@West.Sun.COM (Stanley Friesen
[Contractor]) wrote:

[snip]

>Which in fact solves Gene's issue with gcc, as gcc supports this method.
>
>When using gcc in a case where core dumps are unacceptible, I set up
>signal handlers for everything.

Wouldn't that pretty much shoot portability in the proverbial foot?

William Bloodworth

=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
=====================================================================



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0620e5145171e89CPIMSSMTPE01@msn.com>,
Gene Bushuyev <gbush@my-deja.com> wrote:
>Division by zero is detected on a processor level. This is one of many
>operations when processor sets corresponding flag and causes interrupt only
>when this condition occures. There is no overhead otherwise. Using NaN or
>Infinity is a great overhead indeed with any scenario.

Umm, NaN and Infinity are also often supported at the processor level.

That is certainly the intent of the floating point standard

So, again, where is the extra overhead?  Either way one is doing something
special at the processor level, and I suspect that NaN and Infinity make
fewer special demands on processor mechanisms than async interrupts.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37cccdde.37050535@news.airmail.net>,
William H. Bloodworth <whbloodworth@usa.net> wrote:
>
>On 31 Aug 99 05:33:54 GMT, stanley@West.Sun.COM (Stanley Friesen
>[Contractor]) wrote:
>
>[snip]
>
>>Which in fact solves Gene's issue with gcc, as gcc supports this method.
>>
>>When using gcc in a case where core dumps are unacceptible, I set up
>>signal handlers for everything.
>
>Wouldn't that pretty much shoot portability in the proverbial foot?
>
Signal handling like this is portable to *all* Unix platforms.

And the C standard requires a certtain minimal capability in this area,
which permits even wider portability.

So, in fact, as it stands, handling these as signals is actually more
portable than handling them as "structured exceptions".


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stanley Friesen [Contractor] <stanley@West.Sun.COM> wrote in message
news:7qgve8$ftt@abyss.West.Sun.COM...
[snip]
> Umm, NaN and Infinity are also often supported at the processor level.
>
> That is certainly the intent of the floating point standard
>
> So, again, where is the extra overhead?  Either way one is doing something
> special at the processor level, and I suspect that NaN and Infinity make
> fewer special demands on processor mechanisms than async interrupts.

Extra overhead comes not from the way processor operates in these cases.
Extra overhead is inevitable in the program itself.
There are three possibilities.
One, verify that parameters supplied to the expression are all correct and
do not cause div by zero or similar problems. This is very bad approach.
The second, verify that the result of expression is valid. And this has to
be done in EVERY expression and then program must make corresponding
decisions after EVERY expression. This is what exceptions were supposed to
make unnecessary.
The third, let the useless data propagate to the end. The whole program run
is an overhead.
Whatever approach you choose, it's inconvenience and overhead.
In case of exception mechanism, you have an overhead only when div by 0
occures and FP unit causes interrupt that throws exception, not otherwise.

Gene Bushuyev




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:

> In real programs you must have the
> ability to catch all this different types of errors that standard defines as
> undefined behavior.

In real serious programs, you just avoid division by 0.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37C6C6DE.6A24@wanadoo.fr>,
Valentin Bonnard  <Bonnard.V@wanadoo.fr> wrote:
>Christopher Eltschka wrote:
>> VC++ AFAIK generates a "structured exception", which is a
>> Windows specific thing; C++ exceptions are just a special
>> sort of structured exceptions, and catch(...) catches all
>> structured exceptions (and therefore all C++ exceptions as
>> well).
>
>Why the structured exceptions don't derive from
>std::logic_error is beyond me.

Because, as he said, *any* C++ exception is a structured exception (in
fact, there's nothing C++-specific about structured exceptions;
they're part of the Windows ABI).  In other words, std::logic_error
"derives" from this structured exception thing, if you want to look at
it that way.
--
   Rob Macomber
    (rmacombe@u.arizona.edu)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>> VC++ AFAIK generates a "structured exception", which is a
>> Windows specific thing; C++ exceptions are just a special
>> sort of structured exceptions, and catch(...) catches all
>> structured exceptions (and therefore all C++ exceptions as
>> well).

Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>Why the structured exceptions don't derive from
>std::logic_error is beyond me.

The VC++ documentation seems to imply that structured exceptions
come from a time before VC++ supported (at least fully) C++
exceptions. Like so many other things in VC++, they are the way
they are for compatibility with old code.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0bdc65622011d89CPIMSSMTPE01@msn.com>, Gene Bushuyev
<gbush@my-deja.com> writes
>Yes, standard could mandate throwing exception when division by zero
>happens. It's obviously exceptional situation and systems that offer NaNs
>make a disservice to programmer. It's not feasible to verify NaN after each
>arithmetic operation. If not caught that NaNs can be lost somewhere and get
>erroneous results without user even knowing it. Even if they are not lost,
>seeing NaN in the output doesn't give you much, only says about time spent
>in vain. This is absolutely impractical approach.

For you may be, for many working in numerics it is close to being an
essential tool.  BTW one feature of NaNs is that they propagate and do
not get lost.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
> news:DuV1XmAWT9x3EweF@robinton.demon.co.uk...
> > You mean that the C++ Standard should mandate that divide by zero will
> > throw an exception?  I would be very unhappy if it did.  Some systems
> > support NaNs and divide by zero should generate a NaN on such a system.
> >
> Yes, standard could mandate throwing exception when division by zero
> happens. It's obviously exceptional situation and systems that offer NaNs
> make a disservice to programmer. It's not feasible to verify NaN after each
> arithmetic operation. If not caught that NaNs can be lost somewhere and get
> erroneous results without user even knowing it. Even if they are not lost,
> seeing NaN in the output doesn't give you much, only says about time spent
> in vain. This is absolutely impractical approach.
>

There are other views on the usefulness of NaNs. The whole point is that
they propogate through the computation (I don't know of any situation
where they "can be lost somewhere"), and that saves having to check
every step along the way. I suspect that that's most useful in
debugging.

One correction, however: division by 0 does not produce a NaN. It
produces infinity. Infinities also propogate through computations,
although dividing infinity by infinity (positive or negative) produces a
NaN.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kevin Kostrzewa wrote:
>
> Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
> > Why the structured exceptions don't derive from
> > std::logic_error is beyond me.
>
> structured exceptions in MSVC are a C and C++ concept, not just a C++
> concept, so that's why.  You can provide a mapping from structured
> exceptions to std::logic_error, though, via _set_se_translator.

I see now.

But it could still derive from std::logic_error,
C programmers would just never know.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0bdc65622011d89CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
<gbush@my-deja.com> wrote:

> Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
> news:DuV1XmAWT9x3EweF@robinton.demon.co.uk...
> > In article <0025d3137021c89CPIMSSMTPE01@msn.com>, Gene Bushuyev
> > <gbush@my-deja.com> writes
> > >It's very deplorable that standard delegates details of handling such
> > >situations to the compiler. It's quite obvious that you can't live with
> > >"core dump" that gcc offers, or your customers stop buying your products.
> [snip]
> > You mean that the C++ Standard should mandate that divide by zero will
> > throw an exception?  I would be very unhappy if it did.  Some systems
> > support NaNs and divide by zero should generate a NaN on such a system.
>
> Yes, standard could mandate throwing exception when division by zero
> happens. It's obviously exceptional situation and systems that offer NaNs
> make a disservice to programmer.

Do you even understand what NaNs are for? They are to simplify things, not
make them more complex.

> It's not feasible to verify NaN after each
> arithmetic operation.

That's the point of them - not having to check after every operation!

> If not caught that NaNs can be lost somewhere and get
> erroneous results without user even knowing it. Even if they are not lost,
> seeing NaN in the output doesn't give you much, only says about time spent
> in vain.

Actually, it's much better than getting a bogus answer.

> This is absolutely impractical approach.

Better tell that to IEEE.

> > Of course there should be a mechanism for handling such things as divide
> > by zero but it should be left to an implementer to decide how and
> > document it.  In the case of 'divide by zero' I doubt that many
>
> Why should it be left to an implementor to decide? BCB, for example, throws
> EDivByZero exception and it's very convenient. Why can't standard specify
> similar behavior? Divizion by zero is quite common error, why should the
> program behave differently depending on the compiler?

Who says divide by zero is caught without any performance overhead, and
that a C++ exception can be reliably thrown when this condition is
detected?

> > programmers would trap it anyway.  If you are writing robust, fault
> > tolerant, mission critical software you need suitable tools and gcc
> > clearly does not match this requirement (neither IMO does Visual C++)
>
> Whatever software you may write, division by zero may happen. Out of bounds
> input data, singular matrices, etc. may cause division by zero.

Out of bounds data, if not checked, could just as well overwrite memory.
If you need this kind of "padded" access, then use a class that does
checking of all operations. Such extensive required checking for built-in
types goes against C++.

> Often
> programmers wrap such code in try block and when exceptions caught notify
> user about wrong input or modify calculations to avoid this error, or
> whatever other actions may be necessary.

How about just checking for zero before the divide? Seems pretty simple to me.

> Division by zero is not the only error that must be standardized. The same
> situation is with over- and underflow, invalid operation, range check
> exceptions.

Does most hardware that C++ runs on automatically do overflow and
underflow checks without any performance overhead, and allow one to trap
these and turn them (reliably) into a C++ exception?

> There is nothing system specific in these errors that standard
> may leave it to the discretion of the compiler vendor.

Are you under the impression that all other processors in use have the
same features as Intel processors?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0025d3137021c89CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
<gbush@my-deja.com> wrote:

> It's very deplorable that standard delegates details of handling such
> situations to the compiler.

Really. It would be better if they forced compiler vendors to be
non-standard if they wanted to allow the programmer to handle these kinds
of errors in a robust way.

Who says that handling a pointer exception, divide by zero, etc. can be
handled with the C++ exception handling mechanism in a robust way?

> It's quite obvious that you can't live with
> "core dump" that gcc offers, or your customers stop buying your products.

And we all know that before exceptions, programs were incapable of
handling errors... yeah, whatever.

Also, one might write higher-quality software that doesn't core-dump in
the first place.

> Borland, for example, to address this problem has more than 70 classes
> derived from a single class Exception.

Sounds like a bunch of stuff. 70 classes?!?

Is this a usable solution in its context? Is it usable outside its context
(i.e. for different operating systems and computer architectures)? Would
it preclude other handling schemes if it were mandated by the standard?
Would it provide enough benefits to justify the cost of adding it?

> In real programs you must have the
> ability to catch all this different types of errors that standard defines as
> undefined behavior.

Catch doesn't have to mean "catch"ing an exception. For example, signals
provide a way to handle many low-level errors Unix-type operating systems.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Robert J Macomber wrote:
> In article <37C6C6DE.6A24@wanadoo.fr>,
> Valentin Bonnard  <Bonnard.V@wanadoo.fr> wrote:
....
> >Why the structured exceptions don't derive from
> >std::logic_error is beyond me.
>
> Because, as he said, *any* C++ exception is a structured exception (in
> fact, there's nothing C++-specific about structured exceptions;
> they're part of the Windows ABI).  In other words, std::logic_error
> "derives" from this structured exception thing, if you want to look at
> it that way.

Since a structure exception is not a C++ class, std::logic_error cannot
be derived from it, at least in the C++ sense. You can't say
'catch(__structured_exception)', and that's the problem.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37c5c53b.1523670@news.airmail.net>, William H. Bloodworth
<whbloodworth@usa.net> writes
>I have yet to find any documentation on what type of exception should be
>thrown in this divide-by-zero situation.  IMHO, it should be a logic_error
>exception.

This is a system level exception.  There is no requirement in the
Standard to handle this level of exception. So in this instance both
compilers are correct, so would code that ignited you computer.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William H. Bloodworth" wrote:
>
> The following code throws an exception...but of what type?
>
> int main (void)
> {
>    double d(0.);
>    long   l(0);
>
>    try
>    {
>       d = 10 / l;
>    }
>    catch (const exception & error)
>    {
>       cerr << "Exception:  " << error.what() << endl;
>    }
>    catch (...)
>    {
>       cerr << "Unhandled Exception!" << endl;
>    }
>
>    return 0;
> }

The code has undefined behaviour.
That is, it _may_ throw an exception, or it may exit the
program with "Division by 0", or it may assign d some
random value and go on, or it might assign d some special
value (like NaN in IEEE numbers) and go on, or <insert
your favourite behaviour here> or <insert the behaviour
you'd dislike most here>.

>
> Using M$ VC++ 6.0 SP2, "Unhandled Exception!" is printed.

VC++ AFAIK generates a "structured exception", which is a
Windows specific thing; C++ exceptions are just a special
sort of structured exceptions, and catch(...) catches all
structured exceptions (and therefore all C++ exceptions as
well).

> Using g++ under Linux Redhat 6, no exception is caught at all and the
> output is "Floating point exception (core dumped)".

This has nothing to do with C++ exceptions; the exception
is a processor exception; those are mapped to C signals in
gcc/g++ (and AFAIK all Unix environments). Especially a
floating point exception is mapped to SIGFPE. This explains
why you cannot catch this "exception" - if you want to
intercept it, you must install a signal handler for SIGFPE.

>
> I have yet to find any documentation on what type of exception should be
> thrown in this divide-by-zero situation.  IMHO, it should be a logic_error
> exception.

A compiler writer could well decide to throw a logic_error
exception. Or he could decide to do something completely
different. That's what "undefined" means: Whatever the
compiler does is correct, and you don't even have to
document it.

>
> Anyone know what is actually being thrown?

VC++: A MS-specific "structured exception".
g++: Nothing. Instead a signal is raised.

>  Or, what SHOULD be thrown
> according to ANSI/ISO C++ standards?

Whatever the compiler writer likes (including nothing at all).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William H. Bloodworth" wrote:
>
> The following code throws an exception...but of what type?
>
> int main (void)
> {
>    double d(0.);
>    long   l(0);
>
>    try
>    {
>       d = 10 / l;
>    }
>    catch (const exception & error)
>    {
>       cerr << "Exception:  " << error.what() << endl;
>    }
>    catch (...)
>    {
>       cerr << "Unhandled Exception!" << endl;
>    }
>
>    return 0;
> }
>
> Using M$ VC++ 6.0 SP2, "Unhandled Exception!" is printed.
> Using g++ under Linux Redhat 6, no exception is caught at all and the
> output is "Floating point exception (core dumped)".

In Win32, this throws a C "structured exception", not a C++ exception.
In MSVC++, I believe it is only catchable via a "..." catch clause. In
Borland C++ Builder, you can catch it using type "unsigned int", and get
the actual numeric exception code.

Outside Win32, this normally aborts the program, since math errors are
not considered C++ exceptions, and there is no alternative mechanism.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

whbloodworth@usa.net (William H. Bloodworth) writes:

> Using M$ VC++ 6.0 SP2, "Unhandled Exception!" is printed.
> Using g++ under Linux Redhat 6, no exception is caught at all and the
> output is "Floating point exception (core dumped)".
>
> I have yet to find any documentation on what type of exception should be
> thrown in this divide-by-zero situation.  IMHO, it should be a logic_error
> exception.

For MSVC++, you can translate the exception from a structured
exception (caught by catch(...)) into a C++ exception (caught using
the type system) via the Win32 function _set_se_translator.

--
kevin kostrzewa
work: kkostrzewa@csisolutions.com
home: tkkost@newsguy.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:

[ Code doing a division by 0 ]

> > Using M$ VC++ 6.0 SP2, "Unhandled Exception!" is printed.
>
> VC++ AFAIK generates a "structured exception", which is a
> Windows specific thing; C++ exceptions are just a special
> sort of structured exceptions, and catch(...) catches all
> structured exceptions (and therefore all C++ exceptions as
> well).

Why the structured exceptions don't derive from
std::logic_error is beyond me.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

William H. Bloodworth wrote:
>    catch (const exception & error)
>    {
>       cerr << "Exception:  " << error.what() << endl;
>    }
(in reference to division by zero, which need not throw an exception,
but that point's been well covered.)

Expecting catch( std::exception& ) to work like catch(...) is a common
mistake.  There's no guarantee that all exceptions -- whether thrown
by you or by the implementation -- will derive from std::exception.

I can find one general statement about std::exception in the standard:

      The class exception defines the base class for the types of
      objects thrown as exceptions by C++ Standard library components,
      and certain expressions, to report errors detected during
      program execution.            18.6.1 [lib.exception] paragraph 1

Regarding the standard library, I'm not sure whether this is intended
to be descriptive, meaning "the exceptions which this standard requires
the standard library to throw are derived from std::exception," or
prescriptive, "all exceptions thrown by the standard library shall
derive from std::exception."

As for exceptions thrown by expressions, I don't see any way this passage
could be taken as prescriptive -- the standard would have to spell
out what "certain expressions" means.

                                                --Lisa Lippincott
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

It's very deplorable that standard delegates details of handling such
situations to the compiler. It's quite obvious that you can't live with
"core dump" that gcc offers, or your customers stop buying your products.
Borland, for example, to address this problem has more than 70 classes
derived from a single class Exception. In real programs you must have the
ability to catch all this different types of errors that standard defines as
undefined behavior.

Gene Bushuyev

William H. Bloodworth <whbloodworth@usa.net> wrote in message
news:37c5c53b.1523670@news.airmail.net...
>
> The following code throws an exception...but of what type?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The following code throws an exception...but of what type?

int main (void)
{
   double d(0.);
   long   l(0);

   try
   {
      d = 10 / l;
   }
   catch (const exception & error)
   {
      cerr << "Exception:  " << error.what() << endl;
   }
   catch (...)
   {
      cerr << "Unhandled Exception!" << endl;
   }

   return 0;
}

Using M$ VC++ 6.0 SP2, "Unhandled Exception!" is printed.
Using g++ under Linux Redhat 6, no exception is caught at all and the
output is "Floating point exception (core dumped)".

I have yet to find any documentation on what type of exception should be
thrown in this divide-by-zero situation.  IMHO, it should be a logic_error
exception.

Anyone know what is actually being thrown?  Or, what SHOULD be thrown
according to ANSI/ISO C++ standards?

Thank you,

William Bloodworth

=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
=====================================================================



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William H. Bloodworth" wrote:
>
> The following code throws an exception...but of what type?
>
> int main (void)
> {
>    double d(0.);
>    long   l(0);
>
>    try
>    {
>       d = 10 / l;
>    }
>    catch (const exception & error)
>    {
>       cerr << "Exception:  " << error.what() << endl;
>    }
>    catch (...)
>    {
>       cerr << "Unhandled Exception!" << endl;
>    }
>
>    return 0;
> }
>
> Using M$ VC++ 6.0 SP2, "Unhandled Exception!" is printed.
> Using g++ under Linux Redhat 6, no exception is caught at all and the
> output is "Floating point exception (core dumped)".
>
> I have yet to find any documentation on what type of exception should be
> thrown in this divide-by-zero situation.  IMHO, it should be a logic_error
> exception.
>
> Anyone know what is actually being thrown?  Or, what SHOULD be thrown
> according to ANSI/ISO C++ standards?
>

The C++ standard says that the effect of dividing by 0 is undefined. MS
has this non-standard thing of allowing C++ catch clauses to handle
OS-generated exceptions. You'll have to ask them what it means.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]