Re: Complexity of new hardware

On Sun, Apr 26, 2009 at 3:10 PM, Gribb, Gil <[email protected]> wrote:
>
> Seem like the death of C/C++ has been proclaimed for at least 20 years. As
> game developers, for say at least the last 12 years or so, we have done lots
> of work with scripting languages of all sorts. Outside of the game proper,
> we use all tools available including really high level stuff like commercial
> databases. So it isn't like game developer are just oblivious to language
> technology.
>

I don't think the death has been proclaimed or even predicted, merely wished
for :-)


> To me, "ownership and lifetime" is an important concept in software
> engineering.  When is something created, when is it destroyed and what
> higher level object is accountable for it? Garbage collection offers ONE
> answer to the question of ownership and lifetime: Everyone referencing
> something share ownership and the lifetime lasts until it can't be referred
> to anymore.
>

You don't say which language you're referring to, but there is nothing about
garbage collection that excludes all other forms of resource management from
co-existing with it. At worst you may need to live with the memory being
"backed" by garbage collection at the bottom (though most "full blown"
languages offer an escape hatch), but you could usually just allocate a big
block (that's garbage collected) and portion it out manually from there.
There's no reason why you couldn't use RAII or even manual resource
management in many high level languages that also have garbage collection.

However, I'd wager that the vast majority of allocations are not special
enough to need manual care, having a built in efficient system for
automatically dealing with it in a way which is guaranteed to never corrupt
the heap is jolly convenient.

Also, not having to worry about memory fragmentation over time is pretty
sweet too. That's definitely an issue a lot of people spend a lot of
engineering effort to work around.


>
> As far as development time and bugs, well in my experience a garbage
> collection system just gives you different sorts of bugs. With garbage
> collection, you will spend your debugging time trying to understand what
> link in super complex dependency chain is problematic, and even when it is
> identified you are left with only hacky approaches to breaking the
> undesirable links. Realize that with a console game, an object that does
> not get destroyed soon enough is just as fatal as an object that gets
> destroyed too soon, except the former is much harder to track down and fix.
>

This would happen in a system with automatic memory management too, except
rather than getting bloated memory with a nice heap you could inspect using
a variety of tools to find the unwanted reference, you get a bunch of stale
pointers to random memory because the data they pointed to has been deleted
from somewhere else.
Yes, you may need to manually null out a few references to avoid space
leaking, but in those instances you'd almost certainly need to do something
equivalent for a manually managed system too (and if you mistakenly didn't
it would be a lot harder to track down).

Compare this to double deletes, memory leaks and scribbles which are often
manifested as heisenbugs, I would definitely prefer these rare and easily
fixed issues that GC has.

You're absolutely right that it's not a perfect solution, and you'd
definitely need to spend some effort dealing with memory management issues
even with a garbage collector, but it does solve (or at least makes it
easier to track down) a lot of the pedestrian hassle of doing it manually.

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

------------------------------------------------------------------------------
Crystal Reports &#45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty&#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list