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