Order of destruction when garbage collection kicks in

[Regan Heath]

On Tue, 09 Apr 2013 20:55:09 +0100, Henning Pohl <henning at still-hidden.de>  
wrote:

> In fact there is no order of destruction. And this is one of the most  
> annoying D problems I recently had to deal with. Look at this example:  
> http://dpaste.dzfl.pl/f3f860b0. This time, it segfaulted. Next time it  
> may (in theory) not, because the dtor of a is called before the one of  
> b. A holds a reference to a B. In the destructor of A I expect b either  
> to be null or a valid instance of B (which has not been destroyed yet).  
> You get a kind of undefined behavior instead. This is IMO a huge  
> drawback towards reference counting with strong/weak references.
>
> Is there right now any way to arrange things?

Have a look at C# and the dispose pattern:
http://msdn.microsoft.com/en-gb/library/fs2xkftw.aspx

You can implement this in D albeit without the hook into the GC to  
"prevent finalization" because that concept does not exist.

In D you would..
- Your object implements a Dispose method which calls a protected/private  
Dispose(bool) with true.
- Your object destructor calls Dispose(bool) with false.
- In Dispose(true) will clean up managed (GC) resources and objects etc.
- In Dispose(false) will only clean up unmanaged (OS handles etc).
- In Dispose(bool) you set a disposed flag to true to prevent further  
disposal.

In your user code you would call Dispose when you were done with an  
object.  This would trigger Dispose(true) and clean up other GC  
resources.  If not called, the destructor will call Dispose(false).

It's not perfect, but it's organised and safe.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/