Constructor bombs for copy objects.

[Mark S. Miller <vlad!mark>]

Date: Thu, 28 Jun 90 05:06:48 PDT
   From: xanadu!michael (Michael McClary)

   ...

   > Coding the constructor & destructor so the destructor knows how much
   > to clean up is quite possible (Michael has a recommended technique),
   > but is quite error prone and has some overhead.

   The approach I described is still my preferred approach, and I take
   issue with your characterization and conclusions.

   Bombs should do only those things which must be done differently when
   something fails.  Undoing successful early stages of construction should
   be done by the same code that undoes them during normal destruction.

   When coded with this in mind, my approach is considerably less error-prone
   than attempting to replicate (perhaps several times) the appropriate amount
   of destructor code as bombs to plant at each stage of the construction, and
   it's a LOT easier to test.  Also, storing a constant in a variable as each
   stage completes has considerably less overhead than planting, arming, and
   disarming a bomb.

   ...

On overheads: My technique is less run-time efficient for the reason
you point out, but your technique is frighteningly less space
efficient since (if I understand correctly) you require a "progress"
style member variable not just per object, but per object times
inheritance depth of the object.  On the other hand, my technique is
academic as it is impossible to implement in the language as is
(although it isn't academic wrt what we should recommend).  Therefore,
the important question is: how can we implement your technique without
the space overheads.  Here's the start of an idea.

(Btw, even though I'm frightened by the above space overheads, I
recommend not investigating the proposal below till performance
engineering phase.  By pre-computing most things in pseudo-
constructors beforehand, we can keep these issues out of most
constructors)

What if we made an "operator new()" which stacked the object being
constructed.  We then always allocate such object with a NEW macro
which (after successful return from construction) popped the top of
this stack.  (Needless to say, we would need a stack per process.)  In
addition, for each object on the construction stack we have a progess
stack.  The depth of the progress stack reflects the depth of
inheritance through which we've constructed the corresponding object.
Each element of the progress stack functions as a "progess" variable
which represents how far we've gotten at this inheritance depth.
Although it's more costly of run-time, we only keep around extra
storage for objects under construction.

This is far from worked out (e.g., when during the processing of the
detonator string to we process the stack), but seems like a promising
approach which could also avoid needing to use "assignment to this".

As for which of our original two techniques are more error prone,
let's do that in person ;-}