GC support in the language has one major advantage over not having it: if the compiler and GC layer cooperate, the language can do type-accurate garbage collection. That's pretty much impossible with a 'guess if this bit pattern is a pointer' implementation like Boehm. (But still, why GC in a C/C++ program? Easy: sometimes, the lifespan of allocated regions is complex enough that you don't want to track it in your own code. A lot of large C/C++ systems have garbage collectors in them, often hand-rolled. GCC does, for instance, and while its effect on data locality slowed GCC down a lot, it *also* wiped out huge piles of otherwise-intractable bugs. In my own coding I find that Apache-style mempools and disciplined use of ADTs eliminates most of the need for GC while retaining the nice object-lifecycle benefits of C/C++, so I can use RAII without fear. Losing that pattern in Java is a major reason why I try to avoid the language: in effect Java eliminates memory leaks only to replace them with other sorts of resource leak because you can't use RAII to clean them up for you...)
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds