The fact that it is trivially simple to garbage collect both C and C++ code neutralizes the "automatic memory management" advantage, dubious as it was, from C++.
Not really. One reason that you infrequently see C++ programs using garbage collection, is because the language includes some nice tools that mitigate many of the pain points that drive people to use GC in the first place.
If you're using C++ as its own language, you get many of the nice things that come with memory management in dynamic languages, but you don't have to pay for it at runtime (the inclusion of shared_ptr in C++0x is a great example of this, actually). If you merely use C++ as "C with classes" (I'm not saying that you do this...just generally), then you don't see this benefit of the language.
What are you talking about? auto_ptr? shared_ptr? You don't pay for these if you don't use them; the language gives you the option of trading safety for speed. That's what I meant when I said that you don't have to pay for the features.
In any case, the reference-counting used by the safe pointers is probably an order of magnitude less heavy than a garbage collector. Even if you use them, you aren't paying that much...
You don't think it's nitpicky to suggest that C++ gives you automatic memory "for free", as long as you don't ever use it?
Garbage collection is not an "order of magnitude" more heavy than reference counting, and there's more than one axis to measure memory management on --- in fact, there are several axes for allocation transactions alone.
Just as importantly, if you go to Google Code Search and randomly select ten C++ projects that (a) have more than 10,000 lines of ".cpp" and ".i" file code and (b) use shared_ptr, I'm betting you're going to find that 8 of them rewrote some of the memory allocator for performance reasons. All the fancy template BS in the world doesn't save you from the fact that "new" is just "malloc", and there's no one allocator design that works for every program.
