[Prev][Next][Index]
Semantics of trashed
Jim,
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...
Gary
229 Atanasoff Hall, Department of Computer Science
Iowa State University, Ames, Iowa 50011-1040, USA
phone: (515) 294-1580 fax: (515) 294-0258
Reference(s):