auto classes and finalizers

Lars Ivar Igesund larsivar at igesund.net
Thu Apr 6 23:49:06 PDT 2006


Georg Wrede wrote:

> Lars Ivar Igesund wrote:
>> Georg Wrede wrote:
>>> kris wrote:
>>>> Sean Kelly wrote:
>>>>> kris wrote:
>>>>>> Jarrett Billingsley wrote:
>>>>>> 
>>>>>>> Hmm.  'auto' works well and good for classes whose
>>>>>>> references are local variables, but .. what about objects
>>>>>>> whose lifetimes aren't determined by the return of a
>>>>>>> function?
>>>>>>> 
>>>>>>> I.e. the Node class is used only in LinkedList.  When a
>>>>>>> LinkedList is killed, all its Nodes must die as well.
>>>>>>> Since the Node references are kept in the LinkedList and
>>>>>>> not as local variables, there's no way to specify 'auto'
>>>>>>> for them.
>>>>>> 
>>>>>> Heck, the LinkedList dtor /cannot/ rely on the nodes being
>>>>>> valid if they are also managed by the GC :)
>>>>>> 
>>>>>> So, as I understand it, one cannot legitimately execute that
>>>>>> example.
>>>>> 
>>>>> ...unless the LinkedList has a deterministic lifetime :-)
>>>> 
>>>> <g> Touché !
>>> 
>>> Hey, hey, hey...
>>> 
>>> If anybody deletes stuff from a linked list, isn't it their
>>> responsibility to fix the pointers of the previous and/or the next
>>> item, to "bypass" that item??????
>>> 
>>> The mere fact that no "outside" references exist to a particular
>>> item in a linked list does _not_ make this item eligible for GC.
>>> 
>>> Not in the current implementation, and I dare say, in no future
>>> implementation ever.
>>> 
>>> In other words, it is _guaranteed_ that _all_ items in a linked
>>> list are valid.
>> 
>> Not if the linked list is circular (such that all items is linked
>> to), but disjoint from the roots kept by the GC. This memory will be
>> lost to a conservative GC, but can be detected some of the other
>> types around.
> 
> The mere existence of a circular list that is not pointed-to from the
> outside, is a programmer error. Unless one explicitly wants it to be
> collected. But even then it's a programmer error if the items need
> destructing, since the collection may or may not happen "ever".

Maybe it is a programmer's error, but at the same time a programmer expect a
GC to collect memory that is no longer referenced by the program. Also the
list might be generated by a complex enough program to actually make it
difficult to see that it is a circular linked list. Depending on the GC, it
might or might not be able to reclaim this memory (or calling the
destructors/finalizers of the objects in the list), because it no longer
explicitly know about it.



More information about the Digitalmars-d mailing list