[gclist] Finalization and death notices
Tue, 9 Oct 2001 15:29:06 -0600
From: Jerrold Leichter <email@example.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
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
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.