Xref: utzoo comp.lang.eiffel:290 comp.lang.c++:3781
Path: utzoo!dciem!nrcaer!sce!asterix!jimp
From: jimp@asterix.UUCP (Jim Patterson)
Newsgroups: comp.lang.eiffel,comp.lang.c++
Subject: Re: Eiffel vs. C++
Message-ID: <6392@asterix.UUCP>
Date: 23 Jun 89 18:03:47 GMT
References: <2689@ssc-vax.UUCP> <11991@nswitgould.OZ> <2152@vlot.cs.vu.nl> <129@eiffel.UUCP> <12031@nswitgould.OZ>
Reply-To: jimp@cognos.UUCP (Jim Patterson)
Followup-To: comp.lang.eiffel
Organization: Cognos Inc., Ottawa, Canada
Lines: 37

In article <12031@nswitgould.OZ> geof@nswitgould.OZ (Geoffrey Jones) writes:
>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 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.  

This suggestion ignores the significant difference between Eiffel's
Forget builtin feature and more direct memory management primitives
such as C's free. Forget simply clears a reference to an object; it's
still left up to the garbage collector to actually free the object,
and then only if there are not other references. If Forget were
changed to actually dispose of the object (or to perform cleanup
code), then other references to that object within the program
would suddenly became invalid. This negates the major benefit of
a garbage collector, which is to relieve the programmer of the
burden of tracking which objects are or are not still accessable.

Dispose is the more appropriate solution, as it supports an arbitrary
number of references to any object so that the Dispose procedure
is only actually called when there are no remaining references.
One drawback is that the actual timing of a Dispose call is somewhat
arbitrary; this must be considered when designing the class.
-- 
Jim Patterson                              Cognos Incorporated
UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
                                           Ottawa, Ont  K1G 3Z4