This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __attribute__((cleanup(function)) versus try/finally


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]