Destructor order

Jeremy DeHaan via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Mar 18 08:46:24 PDT 2016


On Friday, 18 March 2016 at 15:07:53 UTC, Andrea Fontana wrote:
> On Friday, 18 March 2016 at 15:03:14 UTC, Steven Schveighoffer 
> wrote:
>> On 3/18/16 10:58 AM, Andrea Fontana wrote:
>>> On Friday, 18 March 2016 at 14:53:20 UTC, Steven 
>>> Schveighoffer wrote:
>>>> On 3/18/16 7:44 AM, Nicholas Wilson wrote:
>>>>> [...]
>>>>
>>>> I think technically not true. If you call __dtor directly, 
>>>> it does not
>>>> recurse. But this is an implementation detail.
>>>>
>>>
>>> Why doesn't this print ~B ~A?
>>> http://dpaste.dzfl.pl/0bef0a4316b7
>>>
>>> It raises a bug on my code because dtor are called in "wrong" 
>>> order.
>>> b holds a ref to a, why a is desctructed before b?
>>
>> Structs are contained completely within the class instance 
>> memory block (e.g. the OP's code). Classes are references. 
>> They are not destroyed when you destroy the holder, that is 
>> left up to the GC, which can destroy in any order. And in 
>> fact, it's a programming error to destroy any GC-allocated 
>> memory inside your dtor, because it may already be gone!
>>
>> -Steve
>
> Not the case. I'm writing a binding for a library. Class A and 
> B wrap c-struct and on d-tor I have to free underlying c object 
> calling c-library destroyer. I'm not destroying any 
> d/GC-allocated object. But of course i have to destroy c object 
> in the correct order... How to?

You can't rely on classes to have their destructors call in any 
particular order. My guess is that the GC is going through and 
deallocating them in the order they appear on the heap.

If you need destructors called in a reliable manner, use structs 
instead of classes or call destroy on your objects manually.


More information about the Digitalmars-d-learn mailing list