[gclist] Destructor FAQ

[Hans Boehm]

Post-mortem finalization is basically equivalent to the Cedar/M3/... scheme
based on finalizing in topological order.  If you have an object A with post-mortem
finalization, and the information needed for finalization stored in the "copy"
object B, you can represent the same state of affairs with topological-order
finalization by making sure there's a pointer from A to B and registering B
for finalization.  (This assumes nothing else refers to B directly.  Otherwise
you can add another object in between and register that.)  Note that there are
problems with cycles involving B in either case.

Invoking all finalizers at program exit is tricky, since there is no way to
order the calls to ensure that finalized objects can't be referenced.  I'm
actually not convinced that this is very interesting IF the operating system
is doing its job and cleaning up resources on process exit.  (And I don't
believe that an OS can be reasonably robust without doing that.)  Thanks to
Microsoft and a few other vendors, it does seem to be interesting in some
contexts.  I would prefer to see the user maintain (the right kind of) weak
pointers to these objects and clean them up explicitly at program exit, if
necessary.

Hans
Standard disclaimer ...