Re: Exception Misconceptions
On Dec 12, 10:05 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Dec 11, 11:05 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Dec 11, 8:57 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
[...]
this hypothesis is wrong, at least
for the compilers I know. You also said "An explicit mechanism
that is part of the exception machinery that calls destructors?
I don't think so." I'm not sure what you mean by that,
How convenient for you, since that IS the hypothesis.
but the compiler definitely does generate code which is
specific to exception handling, and it is that code which
calls the destructors.
I guess at this point, nothing else will do except a
side-by-side comparison analysis of the actual processes and
mechanisms of an implementation (or a few implementations).
Thanks for trying to explain it though.
The real problem I'm having, I think, is in understanding
what you mean by "an explicit mechanism". Within the
compiler (and the compiler's runtime library), there is a
lot of code which deals exclusively in exceptions: the
tables generated in my explination are only used in
exception handling, the code which walks back the stack,
looking for the return addresses in the tables is only used
for exception handling, and the separate clean-up routines
called by that code are only used for exception handling.
To me, that's a "mechanism", and it is explicitly used for
exceptions. But maybe you're thinking of something else
with regards to "mechanism".
Yes, you understand "mechanism" the same way as I used it (and
no need to get into the plural of the term, as this is not an
English language learning newsgroup though at times it sure
feels like it). "Umpteen" posts ago, you told of that
mechanism and I asked then what is the mechanism and
processing like in the case where there are no exceptions, say
the compiler switch that turns off exception handling is on.
So far, we have the one mechanism "defined" (for some whatever
implementation) and now I'm in search of the other one for
comparison. I meant "explicit" as "separate from the mechanism
that calls destructors and controls program flow in the case
where there are no exceptions".
OK. In that case, the mechanism I explained is explicit. In
all of the compilers I've seen, destructors are simply called at
the end of scope when no exceptions are raised. Exactly as they
were before exceptions were added to the language. The extra
tables and the associated stack walkback only comes into play
when an exception is thrown.
The goal here is "you don't pay for what you don't use". As
long as no exception is thrown, the code executes as fast as if
exceptions weren't in the language (or almost---added control
flow paths may affect optimization, and the additional tables
may affect locality).
Not all compilers use this technique. G++ does, as does Sun CC,
but Microsoft does seem to insert some extra calls here and
there (although I've not studied its mechanism enough to know
exactly how it works).
Basically, at least with Sun CC (and except for the optimizer
considering the additional flow paths), code is generated
exactly as if exceptions didn't exist. Plus the additional
tables are generated. When you throw an exception, the compiler
generates special code to allocate memory in a reserved area and
copy the exception into it, then calls a special runtime
function which does the stack walkback. Which can be relatively
expensive in runtime, because of all of the table lookup's it is
doing. (I don't know off hand whether it has to do a linear
search each time, of if the tables are sorted, and it can do a
binary search.)
--
James Kanze