At 05:16 PM 7/11/97 +0100, Christoph & Ursula Grein wrote:
>I do not see how a stack should solve the problem. I think the idea with
>stacks is: "Finalize pushes it on the stack, Adjust pops it."
>But: Every Finalize pushes, who pops if there is no Adjust? Eventually the
>     stack will overflow!

   Again, as I said, this is highly platform dependent, but...

   Finalization of the RHS occurs after assignment (and adjusting).  The
LHS is of course finalized before the assignment and components of an
object are finalized before the entire object.  Basically, I set things up
so that all the hard stuff occured during finalization of the object and
two subcomponents.  If there were any objects of the subcomponent types,
yes there would be storage leaks, but those types were only there to do the
magic.  Hmmm... Let me try a better explanation.  The visible type to the
user was a private type implemented as a record containing a pointer.  The
"real" heap objects had a back pointer to the address of the visible
object.   The stack was just used as a shortcut to optimize the mapping
from the address of the visible object to the contents of the heap.  So the
code as written used a limited size stack, then switched to a search of the
linked list.  Messy, but if 99% of your hits are on the first one or two
entries in the stack, well worth it.

     Hmmm... Maybe still not clear.  What I did was store Object and
Object'Address on a short (fixed length) stack, then Adjust comes along and
can do its thing knowing the contents of the "old" value.  If a Finalize
doesn't have a corresponding Adjust, which in my program only occured at
program termination, no big deal.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...