|when to destroy local objects w/ tail recursion ? firstname.lastname@example.org (john43) (2002-05-04)|
|Re: when to destroy local objects w/ tail recursion ? email@example.com (Joachim Durchholz) (2002-05-08)|
|Re: when to destroy local objects w/ tail recursion ? firstname.lastname@example.org (2002-05-08)|
|Re: when to destroy local objects w/ tail recursion ? email@example.com (Tim G) (2002-05-08)|
|From:||Joachim Durchholz <firstname.lastname@example.org>|
|Date:||8 May 2002 00:16:05 -0400|
|Posted-Date:||08 May 2002 00:16:04 EDT|
> function: f( object A)
> object B; // default constructor invoked
> return f( B ); // tail recursion
Note: Tail recursion is really just a special case of tail call
optimization. You can optimize the last call of every subroutine by
replacing it with a jump (modulo some caveats).
You can destruct A immediately before the tail call. Just as you can
destruct any parameters or local objects that aren't used in the
recursive calls (which is the reason why you can't destruct B).
Note that you cannot destruct A if B refers to it. This is just a
variant of the aliasing problem (aliasing is a topic for the vast
majority of optimizations). There are other caveats. Debuggers don't
particularly like tail call optimization, because data is discarded
that might interest the programmer even though it cannot affect future
computation. Control transfer across function boundaries (such as
setjmp/getjmp and exceptions) can interact unfavorably. And I dimly
recall there are other things to consider.
Return to the
Search the comp.compilers archives again.