[gclist] Allowing finalizers to wait for the messiah.

Charles Fiterman cef@geodesic.com
Thu, 22 May 1997 12:36:29 -0500

At 05:42 PM 5/22/97 +0100, you wrote:
>> 1. You've still screwed up on
>>    class foo {
>>         ~foo() { foop = this; }
>>         ...
>>         ...
>>    } *foop;
>I think the programmer's intend is clear there - any previous value of
>foop gets collected next time.

But thats not what your algorithm does. It gets freed this time
with foop still pointing at it. This is massivly unacceptable.

>> 4. In most OO languages such as C++ many objects have interior
>>    pointers so you must be sure no object points to itself or
>>    deal specially with those pointers.
>This is indeed a problem with C++.  I think _most_ OO languages don't
>permit this.

This is how multiple inheritance objects generally hold together and
nothing prevents.
        class foo {
                char x[10];
                char *y;
                foo() y(x) { x[0] = 0; }

>> This can run forever for
>>   class foo {
>>         ~foo() { new foo }
>>         ...
>Of course it can, but I don't think that sort of code is ever useful?

Yes. Not this simple case, but destructors must be general that means they
can create objects. So a foo creates a bar which creates a baz. Maybe the
loop isn't infinite but its bad enough.

Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230

A computer language without garbage collection
  is like a city without garbage collection.