In article 18t@cwi.nl, olaf@cwi.nl (Olaf Weber) writes:
> This is in fact somewhat backward.  The administration for stack
> unwinding is (as a rule) done at the `try', `catch' and `throw', and
> has little impact on the efficiency of function calls.  After all,
> exceptions are rare compared with function calls.  A `try' is a fairly
> expensive statement.

Actually, any function call when there are local destructors is in many ways
equivalent to a try block.  You have to get control while unwinding the stack,
and this is almost exactly what you have to do when catching an exceptions.

Also, at least in our implementation, try is a very cheap operation, almost
free, in fact.  There is a cost in space (extra destructor calls, unwinding
logic, etc) but this code isn't executed until the throw.  The main cost turns
out to be lost optimization opportunities due to extra potential transfer
of control.

> Under both static and dynamic checking, the default `throw (...)'
> means that functions without an exception signature won't suffer the
> overhead of an implicit `try' around the invocation.

A more correct statement is that they won't contain an implicit try block
to get the call to unexpected.  They must have an implicit try around the
invocation if there are any local destructors to be executed.

> With static checking, and errors on a failure to catch an exception,
> such code should never be needed, as the checks are explicitly present
> in the code.  However, since a `helpful' implementation might throw
> exceptions for such things as integer overflow, nearly every function
> would either contain a `try' or throw an exception.

I'm not even sure that such exceptions are allowed by the language, which
has decreed that all exceptions are synchronous.  In any case, this would
obviously be some sort of debugging mode, which is expected to be less efficient


> The current system of dynamic checks implies that the check has to be
> added to just about every function with an exception signature.  This
> might make inlining of these functions impossible for some compilers.

Can't see why it should.  We certainly inline them in our compiler.

> Given the C++ philosophy of `if you don't use it, you don't pay for
> it', the default `throw (...)' seems the most reasonable.

That philosophy has long since disappeared, though I would like to
see a resurrection.

Mike Ball
SunPro