On Monday, 18 February 2013 at 12:54:24 UTC, Benjamin Thaut wrote:
The main problem is that programming with a GC encourages
programming with memory leaks. As the gc will take care of any
leaked memory and you don't get any feedback about how much
memory you actually allocate.
You can apply the same reasoning to any language feature.
Bound checking encourage lazy buffer overflow checking. OOP and
functional encourage indirect branching. And I can go on and on.
Everything that help a programmer is generally good, as long as
getting performances back is allowed with extra work (what
GC.free allows you to do). In other terms, if you free what you
allocate you get back to manual memory management (well, expect
some runtime weirdness).
Also even if you do manual pooling and use a GC you still pay a
big performance impact because the GC will scan the pooled
memory without actually freeing anything. But scanning takes
time too. And those interrupts by the GC will be long enough to
interrupt regular gameplay.
D would at least need a incremental Mark & Sweep to be usable
in games. But in my opinion a GC is not needed at all when
developing games, it makes a lot of sense for other fields
though.
You'll find that in term of memory management, no magic solution
exists. Sometime GC is faster, sometime relying on manual memory
management is the best. Most of a the time an hybrid approach
between several techniques best results.
