Destructing Member Objects

Simen Kjaeraas simen.kjaras at gmail.com
Sun Apr 6 23:21:29 PDT 2008


On Mon, 07 Apr 2008 03:46:31 +0200, Christopher Wright  
<dhasenan at gmail.com> wrote:

> Simen Kjaeraas wrote:
>> On Sun, 06 Apr 2008 06:27:52 +0200, Jarrett Billingsley  
>> <kb3ctd2 at yahoo.com> wrote:
>>
>>> The spec doesn't really specify _why_ destruction order is  
>>> nondeterministic,
>>> however.  You need nondeterministic destruction in order to break  
>>> cycles.
>>> So if A points to B and B points to A, you have a cycle.  In order to  
>>> break
>>> the cycle you have to delete one or the other first.  There's no  
>>> "correct"
>>> order to destroy them.  So, to solve this, you simply cannot guarantee  
>>> that
>>> when an object's destructor is run, that everything that it points to  
>>> is
>>> still valid.
>>  It's worth noting that even if only one object in a relation points to
>> another (i.e. no cycle), the easiest thing for the GC to do is to flag  
>> both
>> as trash, then destroy them in some order when it gets to that point.  
>> If it
>> were to flag only the mother class and destroy that, its child classes  
>> might
>> have to wait until the next GC run before they're deleted.
>>  -- Simen
>
> That doesn't work. The collector flags stuff only as not-trash, never as  
> trash. Then it does a linear scan through each block containing  
> aggregate types and calls destructors.
>
> Well, maybe not, but that's how I'd implement it, if I cared about  
> efficiency.

You're probably right. My point was only that even if there is no circular
reference, there's still a reason to have nondeterministic destruction.


More information about the Digitalmars-d-learn mailing list