🚀 go-pugleaf

> Note in the discussion of handlers for asynchronous exception no reference
> has been made to existing implementations.  I believe Eiffel, and to a
> much lesser extent, Ada, have asynchronous exception handling, and have
> not suffered a significant performance degradation by the inclusion of
> this capability in the language.  Am I correct in my belief, and do other
> languages have such capabilities?

I think this depends on how you define "significant".  Dealing with
asynchronous exception handling in the formal data-flow-analysis 
sense, it really trashes your flow graph.  That should make your 
compilation take longer, and the result should be somewhat slower.
However, I'm not sure that "somewhat" exceeds 10%, most of the time.

As for other languages with async exception handling, I'm pretty
sure that the Acorn Modula-2+ compiler supported it, and it generated
code that was clean and efficient by the standards of its time (1988).
I'm pretty sure that the DEC-SRC M-2+ compiler also supported it, 
and some of that technology may have made it back into the DEC binary 
interfaces.

Oddly enough, I think you can "code to the compiler" with (asynchronous) 
exception handling.  If, in your exception handler, you overwrite 
every single variable that was set in your code (and perhaps visible 
outside the exception handler) and if your flow analysis is looking 
for this trick, then the compiler should generate code that is just 
fine -- since all the exception kills all the values anyway, you 
don't have to stand on your head in the unexceptional case to preserve 
them for the case where control flows into the handler -- that is, 
you can optimize them (there's an interesting dual to control-flow 
here that I really ought to think about a little harder).

David
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]