Order of destruction when garbage collection kicks in

[Regan Heath]

On Wed, 10 Apr 2013 11:08:22 +0100, Regan Heath <regan at netmail.co.nz>  
wrote:

> On Wed, 10 Apr 2013 10:48:30 +0100, Henning Pohl  
> <henning at still-hidden.de> wrote:
>
>> On Tuesday, 9 April 2013 at 20:46:12 UTC, Steven Schveighoffer wrote:
>>> No.  You are not allowed to access any GC-managed resources inside a  
>>> destructor.
>> Okay, I finally found it: http://dlang.org/class.html#destructors. But  
>> it's not listed here: http://dlang.org/garbage.html.
>>> And it won't be null, because that would be extremely costly.   
>>> Consider if 300 objects had a pointer to a block of memory.  Now those  
>>> 300 objects all go away.  By your expectation, if the targeted block  
>>> of memory was collected, the GC would have to spend time going through  
>>> all those 300 pointers, setting them to null.  When they are about to  
>>> all be destroyed.  99.99% of the time, that would be wasted, as those  
>>> 300 objects may not even have destructors that care.
>> I thought about the case when the user sets the reference to null  
>> before the destructor was even called.
>>> A destructor is ONLY for destroying non-GC managed resources, nothing  
>>> else.  Like an OS file handle for instance.
>> Imagine this case:
>> ...
>> Any instance of B always needs to be destructed _before_ the A it's  
>> connected to. How do you express this in D?
>

Actually I got my example a bit wrong.  You can at least destroy the a  
library handle in Dispose(true/false).  But, you cannot call a.Dispose()  
 from b's Dispose(false) and from what you're saying, you cannot free the  
library b handle either.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/