Semantics of trashed


Thanks.  I agree with you about the following.

   Note, however, that "modifies self ensures true" makes quite a different 
   statement.  It says that the value of the Stack isn't known on return 
   from ~Stack().  The difference between an object with an unknown 
   value and one that has been deallocated is enormous.  The former, 
   for example, can be reinitialized by assignment.  Assignment to the 
   latter can cause arbitrary damage that CANNOT BE DESCRIBED AT THE 
   PROGRAMMING LANGUAGE LEVEL, because it is implementation-dependent.  
   In fact, in perverse cases, even an attempt to reference a deallocated 
   variable can cause a program to crash or behave arbitrarily badly.  

The trouble as I see it is that the code one writes for a C++ destructor
does not deallocate the object they are called; that is done by the C++
delete statement.  (Similarly the C++ constructor does not allocate
storage, it just fills it in.)

The problem, then is what to specify in C++ for (constructors and)
destructors.  Should we specify the implementor's point of view
or the client's.  The trouble is that the client of a class in C++
sees the constructor only indirectly, via new, and the destructor
only indirectly, via delete.  But perhaps we should stick with trashed
as it is more informative to clients...

   If there is a language construct, such as "// destructor", that conveys 
   the same information, perhaps it should be used in preference to trashed.

In C++, "// " starts a comment.  So there is no jargon preferable to trashed.

My colleague, Al Baker points out that subtyping can also affect
destructors.  It turns out that a destructor can be inherited...
This means that the modifies clause on a destructor may not be saying
what we want for subclasses...

	229 Atanasoff Hall, Department of Computer Science
	Iowa State University, Ames, Iowa 50011-1040, USA
	phone: (515) 294-1580  fax: (515) 294-0258