__attribute__((cleanup(function)) versus try/finally
Richard Henderson
rth@redhat.com
Wed May 7 00:14:00 GMT 2003
On Tue, May 06, 2003 at 11:29:01AM -0700, Mark Mitchell wrote:
> I think RTH accepts the attribute solution as well. He would prefer
> try/finally, as I would prefer no extension, but I think we are both
> willing to accept the attribute.
To some extent I kind-of like the attribute solution on its own.
It provides much more structured access to cleanups than the
arbitrary block of code that __finally allows.
I'm not sure I want to explain to users that jumping out of the
__finally block (via goto/break/return) will lead to undefined
results. It's less difficult to explain that using longjmp out
of a function (under certain conditions) is undefined.
> In fact, that solution delivers maximum performance:
>
> (1) C functions do not need to have handler code inserted.
This is false. Handler code gets inserted with the attribute too.
> (2) You do not have to transfer control from the EH mechanism to the
> stack frame of the caller in order to perform the cleanups.
This is false as well.
Indeed, I'd expect the most common case would be for the cleanup
function to be expanded inline, and reference data cached in
registers in the function.
> The try/finally solution cannot be implemented with this same
> performance; it will, in fact, exact a performance price, in terms of
> both code space and the speed at which cleanups are run, on all
> systems. On systems with setjmp/longjmp exceptions, both costs will be
> very high indeed.
No, the overhead is identical.
r~
More information about the Gcc
mailing list