How to wrap SDL?

[Stanislav Blinov]

22.01.2011 23:04, Sean Eskapp пишет:
> I'm using the Derelict SDL bindings, and I'm wrapping some parts of SDL in my
> own objects. Originally, I was using classes, but this caused a number of
> errors when the program exited, since Derelict unloaded itself before the
> garbage collector took care of destructing my classes.
>
> So I switched to scope classes. This works fine, but I've been told they're
> being removed from the language (?) and to use structs instead for RAII.
>
> How should I be wrapping this SDL stuff?
>
Sorry for not mentioning this earlier on Derelict forum (that was you, 
right?), I remember I intended to write this but I think I got 
distracted and forgot about it. You can go the other way around:

Since the initial problem with segfaults occurs because the order of 
calling dtors for your objects and dtor for derelict.sdl.sdl is 
indeterminable, you may want to somewhat 'determine' it:

1. Create a module, say, sdlresource.d.
2. In this module, import derelict.sdl.sdl. (see below why).
3. In this module, create a base class for all your SDL wrappers.
4. This base class' (default) ctor should store a 'this' reference in 
some (module-private) storage such as array/AA.
5. This base class' dtor should remove 'this' reference from that storage.
6. Create a static dtor for sdlresource.d, which would iterate the 
storage and delete/clear() all references that are still left at that point.

That's it. You now can use dtors of subclasses to customize SDL resource 
deallocation. Such approach guarantees that DerelictSDL will not be 
unloaded before all your resources are freed (because sdlresource.d 
imports derelict.sdl.sdl). The only caveat that's left is calling that 
dtor. For now, you can still use 'delete', but you'll have to switch to 
clear() later, when it's finished and 'delete' is finally deprecated. 
But that's easily localized by creating something like this:

void safeDelete(T)(T p) if (is(T == class) || is(pointerTarget!(T) == 
struct)) // pointerTarget is in std.traits
{
     delete p; // switch to clear() later
}

With this approach, either the GC will deallocate resources, or forced 
deallocation in sdlresource.d's static destructor will occur.
I agree, this is a hacky method, but it should work well. The 'storage' 
may be a simple array. In this case, for the sake of efficiency, 
resources may be indexed and simple unstable removal (backswapping and 
removing last element) may be used.

PS. The other 'caveat' that actually messes not only this approach, but 
the whole Derelict usage, is that in Derelict modules, loader objects 
(such as DerelictSDL) and static dtors are not shared. (This is actually 
a result of unfinished introduction for handling TLS by default in D2). 
That means that in a multithreaded program, as soon as one of the 
threads finishes, Derelict bindings will be invalidated for the whole 
application. That's nasty, I should probably mention that to aldacron or 
even come up with the fix.

I hope this helps.