Comments on: Exception Destruction http://www.airs.com/blog/archives/257 Ian Lance Taylor Sun, 07 Mar 2010 17:12:02 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Ian Lance Taylor http://www.airs.com/blog/archives/257/comment-page-1#comment-14957 Ian Lance Taylor Tue, 21 Oct 2008 05:44:58 +0000 http://www.airs.com/blog/archives/257#comment-14957 Alan: it is of course possible to implement error handling with single cleanup using goto. Lots of C code is written that way. In a language which doesn't have exceptions, try/finally is just syntactic sugar: useful but not essential. ncm: it's not the destructors which prevent moving instructions across function calls. It's the fact that you can't move an instruction from one exception region to another. That is, when using exceptions, all constructors and destructors must be completely run before or after a function call. It is impossible to spread the instructions for a constructor or destructor across a function call, because you will be in an inconsistent state if an exception is thrown. Cleanup functions aren't any better, I just threw that in as a comment. You're right, in some cases you will win because of skipping the error checks. In code like gold, I wouldn't, because I don't need to do error checks. I can just crash if something goes badly wrong. Alan: it is of course possible to implement error handling with single cleanup using goto. Lots of C code is written that way. In a language which doesn’t have exceptions, try/finally is just syntactic sugar: useful but not essential.

ncm: it’s not the destructors which prevent moving instructions across function calls. It’s the fact that you can’t move an instruction from one exception region to another. That is, when using exceptions, all constructors and destructors must be completely run before or after a function call. It is impossible to spread the instructions for a constructor or destructor across a function call, because you will be in an inconsistent state if an exception is thrown.

Cleanup functions aren’t any better, I just threw that in as a comment.

You’re right, in some cases you will win because of skipping the error checks. In code like gold, I wouldn’t, because I don’t need to do error checks. I can just crash if something goes badly wrong.

]]> By: ncm http://www.airs.com/blog/archives/257/comment-page-1#comment-14943 ncm Sun, 19 Oct 2008 07:51:50 +0000 http://www.airs.com/blog/archives/257#comment-14943 I've read and re-read this posting, and it seems about equally nuts (but in slightly varying ways, according to emphasis) each time. Maybe I don't understand what instructions the compiler might (otherwise) move across which function calls, but can't because of destructors, and how that would have much effect on performance. Aren't the destructors that run in performance critical code inline, anyway, and subject to aggressive optimization? How are cleanup functions better, this way? The measurements I've heard of showed exception-using code substantially faster because many error checks after function calls could be deleted outright. I’ve read and re-read this posting, and it seems about equally nuts (but in slightly varying ways, according to emphasis) each time. Maybe I don’t understand what instructions the compiler might (otherwise) move across which function calls, but can’t because of destructors, and how that would have much effect on performance. Aren’t the destructors that run in performance critical code inline, anyway, and subject to aggressive optimization? How are cleanup functions better, this way?

The measurements I’ve heard of showed exception-using code substantially faster because many error checks after function calls could be deleted outright.

]]> By: Alan Stokes http://www.airs.com/blog/archives/257/comment-page-1#comment-14922 Alan Stokes Thu, 16 Oct 2008 10:15:10 +0000 http://www.airs.com/blog/archives/257#comment-14922 Languages that support *error handling* need to support destructors or they need to support a try/finally construct. Being able to specify cleanup just once is important, but is orthogonal to whether you signal an error via an exception or returning an error code. Languages that support *error handling* need to support destructors or they need to support a try/finally construct.

Being able to specify cleanup just once is important, but is orthogonal to whether you signal an error via an exception or returning an error code.

]]> By: Ian Lance Taylor http://www.airs.com/blog/archives/257/comment-page-1#comment-14920 Ian Lance Taylor Thu, 16 Oct 2008 05:01:32 +0000 http://www.airs.com/blog/archives/257#comment-14920 The cleanup functions are called in the reverse of the order of declaration. In effect each variable with a cleanup attribute implicitly introduces a new try/finally scope. Everything which follows the declaration of the variable is in the try block, and the cleanup function is in the finally clause. The cleanup functions are called in the reverse of the order of declaration.

In effect each variable with a cleanup attribute implicitly introduces a new try/finally scope. Everything which follows the declaration of the variable is in the try block, and the cleanup function is in the finally clause.

]]> By: gps http://www.airs.com/blog/archives/257/comment-page-1#comment-14919 gps Thu, 16 Oct 2008 04:55:57 +0000 http://www.airs.com/blog/archives/257#comment-14919 Looking the gcc cleanup variable attribute up I find this documentation: http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes It doesn't answer one important question: When multiple variables in one scope have a cleanup function, what order are the cleanup functions called in? Looking the gcc cleanup variable attribute up I find this documentation:

http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes

It doesn’t answer one important question:

When multiple variables in one scope have a cleanup function, what order are the cleanup functions called in?

]]>