Re: Software Architecture/Design

You both miss my point: to do GC requires that there exists a system (namely, the garbage collector) that knows or can discover everything about how your program uses memory (or whatever is being collected).

If you can build that system yourself or control it, then it doesn't matter if you use it or not, or if you use a middleware solution or not. The fact that you can do that is the important part. Because how your game uses data is so important that one person/system should be able to manage it.

(Much like the benefit of TDD has value outside of testing.)

MSN
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Thursday, June 10, 2010 5:32 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Software Architecture/Design

> GC makes an easy job easier, by making hard stuff harder.  Worst.
> Compromise.  Ever.
>
> Thaddaeus Frogley

Except when 90% of your time is spent doing the "easy" job. There's plenty
of game programming tasks that don't push the boundaries of resource
allocation. It doesn't matter where that % actually is now, for any given
person or job, it's only a matter of time before it grows past the magic
threshold that makes it a "good" compromise.

In any case, the hard part doesn't really get harder: manually controlled
object lifetime is perfectly doable within a GC system by creating custom
pools. You're probably doing this already even in C++.

-- 
Javier Arevalo
http://www.iguanademos.com/Jare



_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com