[gclist] Finalization and death notices

[Jerrold Leichter]

| > That's almost, but not quite, true.  The real problem is that delete *always*
| > calls the destructor.  If the object has already been destructed, you're dead.
| > You might think you could avoid this by having a flag set in your constructor
| > and cleared in you destructor - but that gives you undefined behavior:  You
| > aren't allowed to look at the object once it's been destructed.  Carrying the
| 
| I've experienced where the virtual function table is modified by the
| DTOR; however, I'm not sure DTOR for POD will make access illegal.
| Consider:
|   struct X{ int a;~X(){}}; X x; x.a=1;x.~X();cout<<x.a;
| Is the last "look at" x.a in the output statement illegal?
| Could you point out in the standard where this is specified?

This is specifically undefined for a non-POD type - see Clause 12.7:

	For an object of non-POD class type (clause 9), before the constructor
	begins execution and after the destructor finishes execution, 
	referring to any nonstatic member or base class of the object results
	in undefined behavior.

Unfortunately, your class *is* of "non-POD class type".  Clause 9 says:

	A PODstruct is an aggregate class that has no nonstatic data members
	of type pointer to member, nonPODstruct, nonPODunion (or array of such 
	types) or reference, and has no user-defined copy assignment
	operator and no user-defined destructor.

I don't know if the Standard says anything one way or another about what
happens if you invoke the (implicitly defined do-nothing) destructor for an
object of POD type.

(Mind you, I don't know of any implementations in which your code would fail -
but an implementation is free to over-write the contents of an object with
random bits as soon as its destructor completes.)

							-- Jerry