Xref: utzoo comp.lang.eiffel:279 comp.lang.c++:3690
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!csd4.milw.wisc.edu!leah!albanycs!crdgw1!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!otc!metro!basser!nswitgould!geof
From: geof@nswitgould.OZ (Geoffrey Jones)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Summary: I erred, Eiffel does/will have destructors.
Message-ID: <12031@nswitgould.OZ>
Date: 14 Jun 89 04:18:37 GMT
References: <2689@ssc-vax.UUCP> <11991@nswitgould.OZ> <2152@vlot.cs.vu.nl> <129@eiffel.UUCP>
Organization: University of Technology, Sydney
Lines: 97

In article <11991@nswitgould.OZ>, I wrote:
> As a small issue in C++'s favour, each C++ class
> can contain a destructor routine which is executed whenever an object
> of that class is destroyed, which will be whenever the object goes out
> of scope (e.g., at program termination) or whenever it is actively
> deallocated from the dynamic memory pool. No such operation exists in
> Eiffel. This makes certain types of programming awkward in the latter.

Oh dear, searching through my comp.lang.eiffel archive I grepped on
"destructor" and found to my surprise that Jos Warmer (jos@cs.vu.nl)
had already raised this point in article <2152@vlot.cs.vu.nl>. I'll
include a little of it here because the article has probably expired
from most sites by now and many comp.lang.c++ people following this
discussion won't have read it before:

> Some problems with garbage collection:
> 
> 1. In the library class FILE one can create a FILE object, open it and use it.
>    If the FILE object is not referenced anymore, the memory used by it
>    will be reclaimed by the garbage collector.
>    However, each file that is opened should be closed before the FILE object
>    is destroyed.
> 
>    This can not be forced by the FILE class, but it is left to the client.
>    It should be much safer if the FILE class could ensure that each file
>    is closed before the object pointing to it is destroyed.
>
     [ ... much more removed ... ]
>
> A possible solution:
> 
> In C++ so-called destructors can be defined.  A destructor is a routine
> that is called on an object when the object is being freed.
> A destructor contains code that performs some cleanup before the object
> is destroyed.
> 
> These destructors can be used to solve the problems described above.
> I cannot find a way to solve these problems in eiffel.  Should such
> a feature be added eiffel, or are there other solutions.

In article <129@eiffel.UUCP> Bertrand Meyer (bertrand@eiffel.UUCP)
follows up to provide a (patch) solution:

>     In version 2.2 the library class MEMORY will include an argumentless
> procedure called dispose, to be invoked by the garbage collector (if
> active) when an object is freed. The original version of this class
> has an empty body and hence does nothing. Any class can inherit
> from MEMORY and redefine this procedure to do something, for instance
> close a file as in Mr. Warmer's example.
> 
> Two caveats:
> 
>     - The exact details are still subject to change.
> 
>     - The next version (Eiffel 3, end of 1989) will support the
>     possibility of treating all objects as persistent (the set of all
>     objects of an Eiffel session becoming a database). In this context
>     the problem addressed by Mr. Warmer becomes part of a larger
>     requirement (describing what should be done to any object when
>     the session terminates, or when it is stored to a file by an automatic
>     mechanism). This means that the 2.2 solution may be overridden at that
>     time by a more general scheme.

The version 2.2 solution is indeed a step in the right direction but I
don't see that it should be the final answer. An "obvious" solution
might be to imbue Eiffel's `Forget' with an enlarged semantics, thus
moving the solution under the auspices of the language definition and
away from all the ad hoccery involving strange class inheritences.  I
would propose that programmers could define their own `Forget'
routines analogously to programmer-defined `Create's.  Thus the
responsibility to call server class terminating routines (e.g.,
`close' in class FILE) would be removed from the server's clients (as
Dr Meyer's v2.2 solution seems to allow), as well as from the vagaries
of the garbage collector which may or may not be active depending on
all sorts of contingencies not the least of which is whether the GC was
enabled at compile-time(!). I believe it would be proper if each class
instance had its programmer-defined Forget routine called whenever
that instance went out of scope of all other system objects, i.e., if
a successful garbage sweep of the object could be made or whenever the
program was terminating.

Naturally these are only tentative thoughts which should be weighed in
the light of added language complexity and so forth. However the
problem of proper object termination is a real one that must be
addressed in the not-too-distant future if Eiffel is to become a
suitable platform for many types of computing tasks.

Geof.

----------------------------------------------------------------------------
Geoffrey Jones            ACSnet: geof@nswitgould.oz.AU
Dept. of Computer Science ARPA:   geof%nswitgould.oz.AU@uunet.UU.NET
U. of Technology, Sydney  UUCP:   ...!munnari!nswitgould.oz.AU!geof
P.O. Box 123,             Or try: munnari!nswitgould.oz.AU!geof@uunet.UU.NET
Broadway, 2007                
AUSTRALIA                 Phone: (02) 218 9505
----------------------------------------------------------------------------