C Memory

[Namespace]

> 1) You don't need to call unload on any Derelict loaders. That 
> is handled automatically by Derelict using static module 
> destructors just as you have here. And that leads to
That good to know.

> 2) Module destructors are run before the gc runs its final 
> collection at shutdown. So if in a destructor you try to call 
> into one of the libraries Derelict binds, you will be calling 
> into a library that is already unloaded, hence the error.
As I thought. But I have currently no real solution for that.

> Never rely on destructors to release memory. Aside from this 
> Derelict-specific issue, you have no control over when, if, or 
> in what order the destructors are called. This can lead to all 
> sorts of subtle bugs.
Never heard of RAII? ;) D structs should be able to do this 
technique.
That's why I do this that way. It's more comfortable and you 
don't forget to free memory.

> The IMO ideal way to handle this is to give your app a 
> terminate() function somewhere that is always called before the 
> app exits and which initiates a clean release of system 
> resources. Assuming a game:
>
> ****
> void main() {
>     initialize();
>     run();
>     scope(exit) terminate();
> }
>
> void terminate() {
>     Game.terminate();
>     Audio.terminate();
>     Network.terminate();
>     Graphics.terminate();
>     ...
> }
> ****
>
> I adopted this style long ago in C and it applies well to D. I 
> never rely on destructors except for logging, statistics, or 
> other non-critical things. I release all C-side memory through 
> a terminate chain.

Well, maybe I could adapt it to my problem. It's a bit annoying 
that you have to call it by yourself.  :)