[gclist] Finalization and death notices

[Greg Colvin]

From: Jerrold Leichter <jerrold.leichter@smarts.com>
> ...
> Dynamically created objects may well have references to things that need
> to be cleaned up, but that's an entirely different thing.  The delete operator
> in C++ is overloaded:  It means *both* "run the destructor" and "free the
> underlying memory".  The second of these operations in invisible to a C++
> program.  I've suggested in the past that, if you want to be friendly to both
> C++ idioms and gc, you need to transparently decouple these two operations.
> To do this, you require that the implementation keep track of whether a block
> of memory has been destructed.  Then the user-visible "delete" operator becomes
> just a destructor call; the actual memory may be freed later by the collector.
> The collector has access to the "has been destructed" flag and thus can avoid
> running the destructor twice.  If you care when the destructor runs, use
> delete (as you do now.)  In correct - according to the current C++ definition
> - code, you can't tell whether delete frees the memory immediately, or waits
> until later:  Any access to a deleted object has undefined semantics.  Any
> visible consequences of delete are necessarily the result of running the
> destructor.

Going back to the above, which for me got lost in this thread.

I think we have seen that destruction and deallocation are
already decoupled in C++, although we may quibble about exactly
how.

The garbage collector Jerry describes, with a delete expression
that only runs the destructor, and memory is cleaned up later,
can already be implemented by a C++ user: just code up a base
class with an appropriate operator new and operator delete.

The only obstacle in the standard to an implementor of C++
providing such a collector is that users are allowed to hide the
value of a pointer (e.g in a file), allow the object pointed to
become unreachable, and then create and dereference another
pointer from the hidden value.  I (and others on the committee)
think such programs should be taken out and shot, but the
committee has yet to be convinced.  I believe the Boehm and the
Great Circle collector already count on programs not doing this.

An alternative would be for the committee to specify an operator
like new(std::gc) for which memory is garbage collected, and
restoring hidden pointers is verboten.