Re: How expensive are exceptions?
on Fri Jun 08 2007, "Sergey P. Derevyago" <non-existent-AT-iobox.com> wrote:
David Abrahams wrote:
void f() { A a1, a2 /* ... */ aN; }
void g() { A a[N]; }
In the f()'s case every aI object is initialized at its own PC
value.
But in the g()'s case every a[I] object is initialized at the
same
code location.
Yes, but, as I've said repeatedly and won't say again, the counter
that tracks which element has been initialized is either in a known
register or in the stack frame. Either way, it's retrievable by the
EH mechanism.
OK, I see I should provide some more information:
1. Your statement that the range table and PC value is sufficient to
unwind
the stack is false. In the case of array construction you also need the
number of elements so far created.
You also need any amount of other data that may be stored on the stack
variables, explicitly or implicitly, including the chain of return
addresses. That data is always there, so I didn't think it worth
mentioning. The loop counter is an implicit automatic variable. It
might even be implemented as an explicit automatic variable in the
runtime library.
2. Your (old good) statament that EH can be build with true zero
runtime overhead is false.
As I said in my previous message and have consistently tried to point
out, it depends with respect to what you are measuring.
At least in the case of array construction compiler must take an
additional effort to make the number of elements so far created
accessible for the EH unwinder. This effort kills certain local
optimizations.
Then name just one, and show how it is killed.
Errors aren't ignored (hint: RAII).
I must be too dense for your hints because they lead me nowhere.
You don't have to write something like:
if (err) {
fclose(f);
return;
}
// OK: do something useful
// ...
fclose(f);
return;
I.e. RAII helps you to deal with errors no matter EH is enabled or not.
I don't see the relevance here. RAII doesn't get you out of checking
err when exceptions are turned off.
But the source code must not be modified, you're only allowed to
turn the EH compiler switch On/Off.
In that case you are measuring against "no error handling."
Suppose you have the following call chain:
f()->g1()->g2() ... ->gN()->h()
In this case h() can throw exceptions and f() contains the corresponding
catch() blocks. The point is that the middle layer g1(), g2() ... gN() can
use RAII no matter EH is enabled or not.
The middle layers cannot propagate an error code if the error
condition was communicated via EH before you turned the switch off.
So that's "no error handling."
I.e. your can compile g_functions.cpp with EH switch turned to On
and Off and compare the object code...
And what does that tell you? Those g functions don't do the same
thing they did before you turned off the EH switch.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]