On Thursday, 27 February 2014 at 13:07:37 UTC, Mike Parker wrote:
On 2/27/2014 9:25 PM, Szymon Gatner wrote:
This is just an example but I would think that it is something
rather
important to have... What about child objects un-registering
themselves
in d-tors from a list that parent object holds and parent is
destroyed
first? What about asynchronous completion handler object that
should
notify some other object that it finished/not finished a job
but a
notifee is already destroyed because application is being
shut-down? I
honestly can't imagine how to reason about object graph
lifetimes in GC
world and I am sure I am missing something very basic.
Probably a very
different mindset.
Two simple rules I follow.
#1 Never rely on class destructors for determinstic clean up
#2 Never rely on class destructors for releasing system
resources
I tend to add two methods to classes that need to do any sort
of set up and clean up: initialize and terminate. Then, at app
exit, I make sure that the terminate methods are called either
with scope(exit) or, if I want to log any exceptions that
percolate up to main, try-catch-finally. Something like this:
class TextureManager {
private TexContainer _loadedTextures;
public void initialize() {...}
public void terminate() {
foreach( tex; _loadedTextures[])
tex.terminate();
}
}
struct Game {
@disable this();
@disable this( this );
private static TextureManager _texMan;
public static void initialize() {
_texMan = new TextureManager();
_texMan.initialize();
}
public static void terminate() {
_texMan.terminate();
}
}
void main() {
scope( exit ) Game.terminate();
Game.initialize();
}
In some parts of a system, for objects that tend to be short
lived, I'll use structs with destructors for RAII. A good
example of this is for vertex and fragment shaders. The shader
programs are long-lived, so those are classes, but I always
destroy the shader objects as soon as any programs that need
them are built. So those are perfect candidates for the
struct-based RAII approach.
RAII is a convenient tool, but it's just that, a tool. One of
the tradeoffs you have to make with D's GC is that you can't
use RAII the same way you do in C++. You *can* use it with
structs, but for classes you're going to have to put C++ out of
your head.
Then the question is why not use structs all the time?
After using D for a bit more as a week I come to the solution
that looks like this.
strict WasAClassInCpp
{
@disable this(); //sadly we can not use ctor in D like in C++
:(
@disable this(this); //this is not a copy constructor, this is
something called after all the data in the struct was copied...
~this(){ ... } //dtor, just like in C++
}
So all my classes in C++ are ported to D structs.
I was using class only to port abstract class from C++.
Replacing it by inerface.
