• Dave Akers (8/8) Sep 15 2015 When a program exits and D's memory management is cleaning up
• Adam D. Ruppe (8/11) Sep 15 2015 All class destructors are called in an undefined order. The

Dave Akers <dave dazoe.net> writes:

When a program exits and D's memory management is cleaning up 
calling all of the ~this's is there a reason it calls the outer 
class's ~this before the inner class's ~this?

I was recently exploring the possibility of using 
https://github.com/bheads/d-leveldb and the example in the readme 
seg faulted, when digging into it i found out that the outer 
class was being destroyed before the inner causing the database 
to be closed before an iterator for the database was destroyed.

Adam D. Ruppe <destructionator gmail.com> writes:

On Wednesday, 16 September 2015 at 01:12:58 UTC, Dave Akers wrote:
 When a program exits and D's memory management is cleaning up 
 calling all of the ~this's is there a reason it calls the outer 
 class's ~this before the inner class's ~this?

All class destructors are called in an undefined order. The 
garbage collector considers the whole object tree to be dead at 
once and just cleans it up in the most convenient order for it.

This means you should not access any member pointers or 
references to things that are managed by the garbage collector in 
a destructor. Manage subobjects manually if you want to destroy 
them in ~this.