Re: Exception Misconceptions
On 11 Dec, 08:57, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Dec 10, 6:50 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Dec 9, 10:33 am, "dragan" <spambus...@prodigy.net> wrote:
I got the idea and material for this thread from the
"high-class" ( ;) ) ng clc++m. Please add any commonly
held/observed misconceptions about C++ exceptions or
exceptions in general. Both mechanism and condition
misconceptions are fine. I'll start...
you'd find life smoother if you lost a bit of attitude...
"Exceptions invoke all destructors while unwinding the stack."
I think that is probably incorrect, though I'm not a
compiler writer so can't say with high certainty that it is
a misconception.
just read the standard then you'd know what an implementation is
required to do. The dtors for all objects that go out of scope must be
invoked.
I hypothesize that the compiler introduces
some kind of "jumps to the closing brace" and lets the
normal destruction of stack class objects happen. An
explicit mechanism that is part of the exception machinery
that calls destructors? I don't think so.
I fail to see the difference. How does your mechanism handle this:
void photon (int x)
{
Fred fred (x);
fred.process(); /* this throws */
George g;
g.process();
}
why isn't g's destructor invoked?
You hypothesize wrong. The usual implementation (except
maybe for Microsoft) is to generate tables mapping code
addresses to clean up functions; the exception propagation
code (in the library) finds the frame pointer from the
stack, uses the table to find the clean up code, and calls
it, for each stack frame. I think some earlier compilers
generated additional code in the constructor to "register"
the class, but the table method is generally considered
preferable, as it has almost no runtime overhead until the
exception is thrown.
What is the mechanism
as described above?
and how does it work in the no-throw
function case?
no destructors are invoked in the nothrow case?
The mechanism is more or less what I described:
Are you saying that there then is NOT a distinct mechanism for exceptions
that does unwinding?
there is a description in the standard that specifies in what
circumstances unwinding is done. How the implementor achieves this is
up to him. Most programming languages work like this.
b = a * 2;
might use an add instruction. Or it might use a shift. You don't care
so long as it gets the right answer.
Since Bjarne Stroustrup was a practical man he didn't specify things
that were unimplementable. I think pretty well everyone does virtual
functions the same way, though the standard doesn't mandate it. I
understand there is more variety in the implementation of exceptions.
I you want assembler you know where to find it!
for each
distinct set of objects to clean up, the compiler generates a
clean-up function, and puts its address in a table along with
the code addresses for which this function is valid.
I hypothesized that there was no mechanism, separate from the case where
there are no exception elements in the code, (read NOT TWO mechanisms) to=
do
unwind explicitly for exceptions and tied explicitly ('distinctly' may be=
a
better word) to the exception machinery. Is that hypothesis right or wron=
g?
there is no madatory mechanism defined by the standard. Some
implementations use what you call "a mechanism". I don't understand
why you care or what you are tryign to make.
(This code
can be destructors or catch blocks. In the latter case, the
compiler also provides information concerning the types for
which the try block is valid.) When an exception is thrown, the
compiler calls code which walks back up the stack. For each
return address it finds, it looks up in the table what it has to
do, and does it.
Typically, the case of nothrow is treated by generating the same
code as if the function were wrapped in a try block, and
handling the error in a catch.
Other solutions are possible. Microsoft, for example, seems to
generate code which is executed in the case where the exception
isn't thrown, although I don't know what it's exact role is.
It sounds like I was right then.
hasn't he just described "a mechanism"? Doesn't that mean you were
wrong?
--
Nick Keighely