How can D become adopted at my company?

Peter Alexander peter.alexander.au at gmail.com
Sat Apr 28 08:16:46 PDT 2012


On Saturday, 28 April 2012 at 09:14:51 UTC, SomeDude wrote:
> On Saturday, 28 April 2012 at 09:12:23 UTC, SomeDude wrote:
>>
>> Real time guarantees on a GC is not something we are going to 
>> offer anytime soon anyway. While a minimal library, loosely 
>> based on the C standard library, with some more bells and 
>> whistles that could be borrowed from Phobos, this is a goal 
>> that is achievable in a foreseeable future. And both game 
>> developers and embedded programmers would be interested.
>
> Note that Kenta Cho, who wrote fast games in D1, used this 
> approach, and it worked very well for him.

I also write games in D.

My approach is this: use the GC all you want during loading or 
other non-interactive parts of the game and then just make sure 
that you don't use it during gameplay.

GC vs. manual memory allocation is a non-issue for real-time 
guarantees. The simple fact of the matter is that you should be 
using neither. I also don't use malloc/free during runtime 
because it has the same non-real-time problems as using the GC. A 
single malloc can stall for tens of milliseconds or more, and 
that's simply too much.

Just learn how to write code that doesn't allocate memory.

A bigger problem with GC for games is memory management i.e. 
controlling how much memory is currently allocated, and what 
systems are using what memory. Having deterministic memory usage 
is preferable for those cases because I know that as soon as I 
delete something that the memory is available for something else. 
I don't get that guarantee with a GC.


More information about the Digitalmars-d mailing list