«

Zorro wrote:

> The concept I am referring to is exceptional events that can happen as
> your program executes. For instance, the operating system does not die
> on a division by 0. It simply aborts your program.

What the operating system does has nothing to do with the issue.

> Thus, the point is that, a C++ compiler's run-time library must sense and
> report such events to your program so you can do something about them.

The point is that all compilers must do what you want just because you like
it that way? If not, there are tons of books and other resources that
explains the reasons for the design decisions of the C++ language.

--
Salu2

Hello!

Zorro wrote:
> The simplicity of stack unraveling of C++ is not without defective
> consequences. The following article points to C++ examples showing the
> defects. An engineer aware of defects can avoid hard-to-find bugs.
>
> http://distributed-software.blogspot...defective.html

I've read this thread, as well as your blog article and referenced
document (which seems to be plugging your Z++), and it seems you're
misunderstanding /why/ the behaviour of division by zero is undefined.

My guess is that the rationale behind it being undefined is something
like the following.

When a processor encounters division by zero, it may well throw an
exception (*not* a C++ exception), complain in some other way, ignore
it, or do something else. What it does depends on the processor. But,
whatever it is, it's beyond the scope of the C++ standard, because the
C++ standard is not there to define such processor behaviour.

If a processor somehow reports division by zero to, say, an operating
system, then that operating system may well respond by sending a signal
to the relevant program, terminating execution of that program, ignoring
it, or doing something else. What it does depends on the operating
system. But, whatever it is, it's beyond the scope of the C++ standard,
because the C++ standard is not there to define such operating system
behaviour.

If the C++ standard was to specify behaviour for division by zero, then
since the processor's behaviour and operating system's behaviour are
beyond the scope of the C++ standard, such specified behaviour may well
have to be implemented in such a way as to prevent the division by zero
from actually occurring in the first place. That would impose often
unnecessary and unwanted overheads. C++ just isn't that sort of language.

Indeed, there are a great many unsafe things that C++ allows programmers
to do. There are unsafe things that C++ allows programmers to do
without even throwing C++ exceptions when they're done. Instead, C++
provides mechanisms for use /when the programmer wants or needs them./
It's the programmer's responsibility to write safe code, /not/ C++
itself. So, C++ provides exception mechanisms /without/ imposing them
on the programmer. If the programmer needs well-behaved exception
handling, the programmer can then use the exception mechanisms provided
accordingly. That's the kind of language that C++ is.

So, if, when doing a division, there's the real (though hopefully
exceptional) possibility of it being a division by zero, the thing to do
is to do that division within a try block, checking for division by zero
before doing the division, and throwing an exception if it would be
division by zero. This could, of course, be wrapped up in your own
number class. No need to change the language itself.



--
Simon G Best
What happens if I mention Leader Kibo in my .signature?

Zorro wrote:
> 5. The defect is in the technique used. Of course it can be
> corrected. Show me a compiler that has in fact corrected this
> problem. The point is that, it takes a great deal beyond plain
> stack unraveling to correct this problem.

Basically, you're just saying that RAII in C++ is broken.
This is a tough statement, you're gonna have hard time proving it...

Incidentally, as others already mentionned it, you should start using
a recent compiler.

Cheers,
--
IR

Simon G Best wrote:
> Hello!
>
> Zorro wrote:
> > The simplicity of stack unraveling of C++ is not without defective
> > consequences. The following article points to C++ examples showing the
> > defects. An engineer aware of defects can avoid hard-to-find bugs.
> >
> > http://distributed-software.blogspot...defective.html
>
> I've read this thread, as well as your blog article and referenced
> document (which seems to be plugging your Z++), and it seems you're
> misunderstanding /why/ the behaviour of division by zero is undefined.
>
> My guess is that the rationale behind it being undefined is something
> like the following.
>
> When a processor encounters division by zero, it may well throw an
> exception (*not* a C++ exception), complain in some other way, ignore
> it, or do something else. What it does depends on the processor. But,
> whatever it is, it's beyond the scope of the C++ standard, because the
> C++ standard is not there to define such processor behaviour.
>
> If a processor somehow reports division by zero to, say, an operating
> system, then that operating system may well respond by sending a signal
> to the relevant program, terminating execution of that program, ignoring
> it, or doing something else. What it does depends on the operating
> system. But, whatever it is, it's beyond the scope of the C++ standard,
> because the C++ standard is not there to define such operating system
> behaviour.
>
> If the C++ standard was to specify behaviour for division by zero, then
> since the processor's behaviour and operating system's behaviour are
> beyond the scope of the C++ standard, such specified behaviour may well
> have to be implemented in such a way as to prevent the division by zero
> from actually occurring in the first place. That would impose often
> unnecessary and unwanted overheads. C++ just isn't that sort of language.
>
> Indeed, there are a great many unsafe things that C++ allows programmers
> to do. There are unsafe things that C++ allows programmers to do
> without even throwing C++ exceptions when they're done. Instead, C++
> provides mechanisms for use /when the programmer wants or needs them./
> It's the programmer's responsibility to write safe code, /not/ C++
> itself. So, C++ provides exception mechanisms /without/ imposing them
> on the programmer. If the programmer needs well-behaved exception
> handling, the programmer can then use the exception mechanisms provided
> accordingly. That's the kind of language that C++ is.
>
> So, if, when doing a division, there's the real (though hopefully
> exceptional) possibility of it being a division by zero, the thing to do
> is to do that division within a try block, checking for division by zero
> before doing the division, and throwing an exception if it would be
> division by zero. This could, of course, be wrapped up in your own
> number class. No need to change the language itself.
>
>
>
> --
> Simon G Best
> What happens if I mention Leader Kibo in my .signature?

There are a number of great comments, but this one sums it up rather
thoroughly.

What seems to be happening is this. When you use "throw", the compiler
generates code to destroy objects in relevant scopes, should an
exception happen. Otherwise, the compiler has no clue where to put such
code. Thus, even though exceptions (such as div by zero) are caught,
the code to call destructors (at end of try, or function body) is
simply skipped.

What that all means, again is this. There is code to destroy objects in
nested scopes. However, unless the "throw" is used, the compiler will
be caught unguarded, and code for destroying objects will be skipped.

That is fair as a standard. The compiler is just doing what the
standard requires, even VC++ 6 does it right. It is also fair to expect
the engineer to check for every possible case of exception and put a
"throw" for it.

I have no further argument on this issue. Just a comment, and nothing
else.

Given that all operating systems report errors (exceptions) rather than
crashing, and in fact the program can even check the error code, etc.
and continue to execute (perhaps taking the necessary actions), how
hard is it for the standard to have a list of common exceptions that
may happen unexpectedly?
The answer is that, the mechanism used in C++ still will need the
"throw" in order to generate code for NOT skipping the destruction of
objects.
I hope this helps, but it is not intended to start another wave. I
agree with all of you.

Thanks for your comments. Have a great day.

Regards,

http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/...Z?lnk=la&hl=en

Zorro wrote:

> Given that all operating systems report errors (exceptions) rather than
> crashing, and in fact the program can even check the error code, etc.

Invalid reasoning, because the premise is false. Unless you use a definition
of "Operating system" that excludes, for example, ms-dos.

--
Salu2

Zorro wrote:
>
> Given that all operating systems report errors (exceptions) rather than
> crashing, and in fact the program can even check the error code, etc.
> and continue to execute (perhaps taking the necessary actions), how
> hard is it for the standard to have a list of common exceptions that
> may happen unexpectedly?

Not all implementations are hosted. Even those that are (UNIX like
systems for example) may signal exception asynchronously. This makes it
extremely difficult to handle the event in the same context as the
running application in order to convert the system event into an
application one.

--
Ian Collins.

Zorro wrote:
>
> What seems to be happening is this. When you use "throw", the compiler
> generates code to destroy objects in relevant scopes, should an
> exception happen. Otherwise, the compiler has no clue where to put such
> code. Thus, even though exceptions (such as div by zero) are caught,
> the code to call destructors (at end of try, or function body) is
> simply skipped.
>

No. If div by zero throws an exception that's implementation-specific
behavior. If your implementation does something silly like not run
destructors as part of its implemenation-specific behavior, that's a
problem with your implementation, not with the language.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

Zorro wrote:
> how
> hard is it for the standard to have a list of common exceptions that
> may happen unexpectedly?

I suspect much harder than it is for you to write

#include <eh.h>

void my_handler(UINT, struct _EXCEPTION_POINTERS* pex)
{
if(pex->ExceptionRecord->ExceptionCode ==
EXCEPTION_INT_DIVIDE_BY_ZERO)
throw divide_by_zero();
}

// main
_set_se_translator(&my_handler);

Zorro wrote:
> how
> hard is it for the standard to have a list of common exceptions that
> may happen unexpectedly?

The standard has a list of all standard exceptions. Keep in mind that
hardware "exceptions" are not the same as C++ exceptions, although they
use the same name. C++ doesn't say much about hardware exceptions,
because they're too idiosyncratic. If you don't throw it, it's not
covered by the standard.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

Zorro wrote:

> What seems to be happening is this. When you use "throw", the compiler
> generates code to destroy objects in relevant scopes, should an
> exception happen. Otherwise, the compiler has no clue where to put such
> code. Thus, even though exceptions (such as div by zero) are caught,
> the code to call destructors (at end of try, or function body) is
> simply skipped.

You're wrong.
`throw' simply throws exceptions.
If you don't use `throw', no exception is thrown. `throw' is the only
way to throw exceptions in C++.
It has been told to you more than ten times already, but division by
zero does *not* throw any exception.



> Given that all operating systems report errors (exceptions) rather than
> crashing

Not all do, on some machines couldn't even allow it.