Re: no-throw guarantee for trivial functions?
On 17 jan, 23:19, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
[snip]
Exceptions specifications don't incure a performance
penalty with a decent compiler,
Could you post compiler names please?
Could you post one where it does have a performance penalty.
I don't know of one. (It certainly has none with Sun CC,
nor g++.)
and can, in a few cases, even lead to improved
optimization (probably only for empty ones, however).
Could you show those cases please?
Not off hand, but as always, the more information a compiler
has, the better it can optimize. Calling a function without
a no throw exception specification introduces an additional
flow path into the program.
[snip]
And so does calling a function with a no throw exception
specification because, if I recall correctly, the
specification is not enforced at compile time but at runtime.
But it's enforced by the usual exception handling mechanisms, in
the called function. When compiling the caller, the compiler
doesn't have to consider the possibility that the function may
return somewhere else (e.g. a catch clause, or whatever is used
to call the destructors).
And of course, the usual exception handling mechanism doesn't
have any runtime cost unless an exception is actually thrown.
Should an unlisted exception try to escape the function,
unexpected() will be called. That means, the control flow
machinery is still in place, just the target for the jump is
different.
You can look at it that way, but the effective result is the
same as if the called function had called abort. Unlike the
case when there's no exception specification, there are no
additional paths that are relevant in the calling function.
On the same note: the compiler does not really have _more_
information. It still has no guarantee that no exceptions will
be thrown. It just has to take different measures to deal with
them.
It knows that no exceptions will perculate out of the functions,
and thus, that there cannot be a precipitous jump to the
destructors of local variables when the function is called.
As an example of how this could affect optimization, imagine a
class with all of its functions inline. The compiler can keep
parts of the class in registers in some parts of the client
function, because it can see all use of them. If you call a
function which might throw, however, it has to somehow ensure
that the class data is where the destructor expects it, and not
just where it should be at the point of return from the
function.
--
James Kanze