Destructors vs. Finalizers

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 26 18:17:23 PDT 2017


On 7/26/17 8:20 PM, Moritz Maxeiner wrote:
> On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer wrote:
>> On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
>>> On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:
>>>> On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
> 
>>> A finalizer may freely work on non-pointer members and pointer 
>>> members that target objects outside the GC pool which the programmer 
>>> knows to be valid at finalization (e.g. they are manually managed).
>>> Whether or not it makes sense for the finalizer to call the 
>>> destructor is something the programmer has to decide on a per use 
>>> case basis.
>>
>> No, because a destructor can safely assume it can look at GC members' 
>> data. So a finalizer can never call it.
> 
> No, whether a finalizer can safely call a destructor depends on the 
> destructor's body.
> If the destructor doesn't access GC members and doesn't allocate using 
> the GC, the finalizer can safely call it. That's why it's the 
> programmer's job to determine this on a use case basis.
>

I suppose this is true, but in practice, you wouldn't in a destructor 
that which is available for a finalizer. In other words, you simply 
wouldn't implement such a destructor.

It's also very fragile as the maintainer of the destructor is working 
under different assumptions from the finalizer. If you call the 
destructor from the finalizer, then the rules of the finalizer infect 
the destructor.

-Steve


More information about the Digitalmars-d mailing list