Order of destruction when garbage collection kicks in
Regan Heath
regan at netmail.co.nz
Wed Apr 10 03:10:38 PDT 2013
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/
More information about the Digitalmars-d
mailing list