jamesh wrote:Never been a fan of garbage collection in embedded devices that require vaguely predictable response times. Causes too many weird effects that you really don't need when trying to encode H264 or run an image through a pipeline. So you really shouldn't be calling languages you don;t like backward - that just shows an ignorance of the requirements.
The main problem with GC is the moving of deallocation work (which remains constant regardless of whether we use garbage collection or not) away from the point where what was once live data becomes "garbage", and thus more work is required to determine if a particular reference is really garbage or not. This does not, however, mean that garbage collection is necessarily non-deterministic; it's perfectly possible to have a real-time garbage collecting implementation (for example, Baker's treadmill
), the main trade-off against manual memory management being additional space requirements vs safety. Even manual reference counting as used in Objective-C provides a safe environment (although with a little programmer effort required), and is usually bounded in time when "garbage collecting" happens (and when it's not, the programmer can not only see what's going on, but also fix it). In short, GC != Boehm (although Boehm, and generational collectors in general, are usually "performant enough" for general usage, particularly on modern computers which have gobs of memory and processing power to spare). On the other hand, try to to anything real-time with Android.
DavidS wrote:Garbage collection has made for some very bad programming practices. And has made it so that many programmers do not bother to look at the way the are allocated memory, or bother to track it in there code, the way they should.
That is almost as bad as Bounds checking done by the language implementation, the programer should be responcable for that, not the language. Learning to do it correctly helps avoid errors.
I'm never sure if you're trying to be provocative or just - well - ...
I'll try and reply anyway, I know I shouldn't, but hey.
Bad programming practices regarding memory allocation have existed forever. They are part of why Windows requires rebooting every now and then, they are part of why games on modern consoles don't run at a steady 60fps although the hardware is capable of doing so, they are a fact of life. They are also, along with lack of bounds checking, part of why there are massive security holes in almost every piece of software out there. "Modern" concepts such as bounds checking and garbage collection go a long way towards fixing that, moving programmer time away from the minutia of managing the machine and spending it, instead, on implementing actual functionality.
Crappy programmers will produce crappy code no matter what.
Yeah, but they're talking about C++, which has a substandard exception model largely built on C's. I largely agree with what they are saying, in that context, but the downside is more programmer effort being expended on writing safe code rather than producing functionality.
 Which was used in the NeXTStep driver model, reference counting garbage collection at the driver level on 30MHz 680x0 machines, and that seemed to work pretty damn well.
 Also Microsoft's COM, Apple's IOKit, etc
 Actually, don't. At least if you value your sanity.
 Again, garbage collection has been around since the '60s
 With C++ you don't have a choice, of course, but I would class C++ as defective by design.