Re: How expensive are exceptions?
on Mon Jun 11 2007, "Sergey P. Derevyago" <non-existent-AT-iobox.com> wrote:
David Abrahams wrote:
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.
I'm tying to emphasize a _conceptual_ point: PC value together with
range
table is insufficient! But without array construction these two do well,
though.
No, there's nothing magical about array construction. It's easy to
see that because I can manually write code that has exactly the same
semantics (and thus the same EH issues) and yet uses no array types.
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.
I'm talking about a _conceptual_ point. It's not a "detail".
It's also not "valid."
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.
More constraints mean less optimizations. I.e. you need to build
very long and complex range tables to be able to fetch the number of
elements so far created from any possible location (good
optimization means any possible location, even XORing two values in
one register!). You'll never find such tables in practice.
Irrelevant. Can you show an example of a local optimization that is
impossible with range table EH, and yet allows the same error recovery
to be implemented by other means, or can't you?
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.
Even with enabled EH you check for local errors. I.e. EH doesn't
mean "no error checking".
Of course not. It means one layer of checking instead of N layers
where N is the depth of the call stack.
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."
You should say "no error handling communicated via EH".
I said exactly what I meant and I stand by it.
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.
Yes, they do. They were designed to be exception-neutral.
No they don't. With EH on they respond correctly to error conditions
detected in h(). With EH off they do not. That's a semantic
difference.
--
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! ]