[gclist] Allowing finalizers to wait for the messiah.

[Charles Fiterman]

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;
                public:
                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
				http://www.geodesic.com

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