yet another +5

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...)