4 ms·
I'm completely in favor of this. Garbage collection has no place in the core definition of any language that targets OS kernels and other high-performance appli
by ambrop7 13y ago
I'm completely in favor of this. Garbage collection has no place in the core definition of any language that targets OS kernels and other high-performance applications. It's sad how we have so many languages that fix many of C++'s problems (e.g. D and Go), but not without the addition of a garbage collector.
- pron 13y agoWith regards to OS kernels you may be right (though not for performance reasons), but some high-performance applications would be very hard to write without a GC, especially if they're to take advantage of multicore. See my explanation above about scalable, concurrent data structures. Even hard real-time systems can benefit from a GC, and Java has a few GC implementations for hard real-time apps. FYI, object allocation and de-allocation for short-lived objects is much faster with a good GC than with dynamic allocation, and even for long-lived objects GC gives a higher throughput than malloc/free. The problem with GC is latency issues (pauses) when maintaining very large heaps with many long-lived objects.