the only bug you can run into with GC is space leaks. these are fortunately very uncommon in eager languages (ie all the mainstream) and debuggers can find them, and patching them is trivial (so far I've only had one case of them).
GC is inherently incompatible with C++. it is very messy/impossible to get compositional properties of GC active in C++ since it requires that most of the code does GC, which is seldom the case. then it should be noted that a good GC implementation need compiler support. otherwise schemes like reference counting has to be used which fails in trivial cases.
C++ is ineffective because of the time it takes to debug and amount of code you have to write for trivial matters. the lack of first class functions and partial application is just the beginning (and please don't get started about Boost; it is a terrible hack).
C++ is almost as portable as C (in practice, the same). that wasn't my point - you don't use a low-level language when it isn't worth the effort. the speed requirements. and your concerns about speed are way beyond function. if 80% of the game time is spent in a few functions (almost always the case) then you optimize there and nowhere else, hence you might as well use a more productive language for all other functions that are less critical.
and no, wrapper code need not grow large. it is a matter of planning.
|