C Memory

[Mike Parker]

On Sunday, 12 May 2013 at 10:11:57 UTC, Namespace wrote:
> I get the error, although I don't call any unload method (or 
> quit any SDL component) and although I recompiled derelict3, 
> where I comment out all static (shared) DTor's.
> Maybe the only solution would be (as you said) to transfer all 
> deallocations into a terminate method, but that is no opinion 
> for me (and would cause a growing memory, if the game runs a 
> long time). And I want to use RAII. So I must live with this 
> invalid memory error.

I think you need to reconsider your use-case for RAII here. 
Wanting to use it is fine, but letting these errors persist just 
so you can do so is not something I would recommend.

What you are missing here is that there's no such thing as that 
this "(and would cause a growing memory, if the game runs a long 
time)" is an issue you are likely to run into by using D's class 
destructors to handle resource deallocation (as I mentioned in a 
previous post), but not with the system I describe here.

You're misunderstanding the purpose of the terminate call. It's 
there not to release all the memory your app ever uses, but to 
clean up any resources /still hanging around/ at shutdown. You 
need to pay special attention to memory management when 
developing a game. RAII isn't going to help you with D's classes, 
but you can still get a comfortable system in place that keeps 
deallocations localized in specific places, allowing you to free 
as few or as many resources as you want. You're likely already 
using some sort of manager structure for most of your game 
systems anyway. Even in a simple Asteroids game you'd have a list 
of Sprites that are active. That list becomes your record of 
resources that need to be deallocated. So just add one function 
that does that, make sure it's called at shutdown, and now you've 
avoided this error you're having. By going with this approach, 
you can have exact control over when resources are released and 
in what order. That should always be an overriding goal in game 
development.

I promise you, this will save you a lot of headaches down the 
road by eliminating a whole class of potential memory-related 
bugs (and they will pop up eventually) and code maintenance 
costs. One of the side-effects of mixing memory managed by the GC 
with that allocated outside of the GC is that you have to be 
responsible for the latter.