Hi !
I wonder if i can rely on this code :

http://dpaste.dzfl.pl/745cc5b1cdfb

There's two questions:
1) Is dtors always called in reverse order ?
2) Is all the dtors always called when i call destroy ?

Thanks for a reply !

On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
> Hi !
> I wonder if i can rely on this code :
>
> http://dpaste.dzfl.pl/745cc5b1cdfb
>
> There's two questions:
> 1) Is dtors always called in reverse order ?
yes
> 2) Is all the dtors always called when i call destroy ?
yes. destroy calls __dtor() which recursively call __dtor() on its members

>
> Thanks for a reply !

On 3/18/16 7:44 AM, Nicholas Wilson wrote:
> On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
>> Hi !
>> I wonder if i can rely on this code :
>>
>> http://dpaste.dzfl.pl/745cc5b1cdfb
>>
>> There's two questions:
>> 1) Is dtors always called in reverse order ?
> yes
>> 2) Is all the dtors always called when i call destroy ?
> yes. destroy calls __dtor() which recursively call __dtor() on its members

I think technically not true. If you call __dtor directly, it does not recurse. But this is an implementation detail.

-Steve

On Friday, 18 March 2016 at 14:53:20 UTC, Steven Schveighoffer wrote:
> On 3/18/16 7:44 AM, Nicholas Wilson wrote:
>> On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
>>> Hi !
>>> I wonder if i can rely on this code :
>>>
>>> http://dpaste.dzfl.pl/745cc5b1cdfb
>>>
>>> There's two questions:
>>> 1) Is dtors always called in reverse order ?
>> yes
>>> 2) Is all the dtors always called when i call destroy ?
>> yes. destroy calls __dtor() which recursively call __dtor() on its members
>
> I think technically not true. If you call __dtor directly, it does not recurse. But this is an implementation detail.
>
> -Steve

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?

Andrea

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:
>>> On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
>>>> Hi !
>>>> I wonder if i can rely on this code :
>>>>
>>>> http://dpaste.dzfl.pl/745cc5b1cdfb
>>>>
>>>> There's two questions:
>>>> 1) Is dtors always called in reverse order ?
>>> yes
>>>> 2) Is all the dtors always called when i call destroy ?
>>> yes. destroy calls __dtor() which recursively call __dtor() on its
>>> members
>>
>> 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

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:
>>>> On Friday, 18 March 2016 at 10:20:40 UTC, Temtaime wrote:
>>>>> Hi !
>>>>> I wonder if i can rely on this code :
>>>>>
>>>>> http://dpaste.dzfl.pl/745cc5b1cdfb
>>>>>
>>>>> There's two questions:
>>>>> 1) Is dtors always called in reverse order ?
>>>> yes
>>>>> 2) Is all the dtors always called when i call destroy ?
>>>> yes. destroy calls __dtor() which recursively call __dtor() on its
>>>> members
>>>
>>> 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?

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.

On 3/18/16 11:07 AM, Andrea Fontana wrote:
> On Friday, 18 March 2016 at 15:03:14 UTC, Steven Schveighoffer wrote:
>> 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!
>>
>
> 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?

Then you need to reorganize how they are related. Even though class B wraps a C resource, it's still stored on the heap, and can be destroyed in any order.

I'd recommend ensuring the dependency requirement is implemented within one object. Either make B a struct member, or have the destruction done by a third object.

-Steve