Left out, which IMHO is a good thing. The C++ language as it stands right now, especially with the C++0x additions has provided plenty of new features that are going to help developers build amazing software with more power.

Not everyone wants or needs garbage collection and it would be a downright pain to bolt it on now.

Feel free to use one of the umpteen other programming languages that does provide garbage collection, clearly if you are complaining about that you are simply using the wrong tool for the job.

C++ has garbage collectors. They're just not standard:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

http://developers.sun.com/solaris/articles/libgc.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n183...

First, it's a bit late to bolt this on to the language now that mountains and mountains of libraries and applications have been written to use manual memory management.

Second, a lot of people use C++ because they need low-level control of memory use and can't tolerate GC pauses. If you're writing the kind of app in which GC is acceptable why not use Java or an even higher level language like Scala instead?

It's really not such a big deal if you use "new" parsimoniously and use containers and RAII as much as you can.

I can count on my hands the number of new and delete I have written in my code in the last three years.

It's rather harder to count the number of times there were idioms you could have used but didn't because using them in C++ wouldn't have been practical or efficient. I'm thinking in particular of closures which captured state, and functional/monadic style chained method calls each building on the previous function's return value (think: something like .NET LINQ).

It sounds like you're referring to C++98 while the article specifically talks about C++0x. C++0x adds closures to the mix so it's now very possible to implement something similar to .NET LINQ in C++.

No, I'm not; I explicitly mentioned closures which capture state precisely because that's where C++0x gets thorny. You can capture by copying or by reference; what you don't get is wholesale movement of the variable into a heap-allocated location, the way variable capture works in almost every other language supporting free mutation of variables.

I wrote about it in an earlier thread: http://news.ycombinator.com/item?id=2617990

My bad, I wasn't familiar with the term. I'm still not convinced this is a limitation though. If you want to modify an object, passing by reference usually makes perfect sense. For those occasion when this is not the case, you probably already have a smart pointer in your hand, capture it by copy. A counter example would be great.

BTW the behavior you describe has been achieved in the C language family with Apple's C block extension, not that it's relevant since it's in no way standard (aside from Objective-C++)

In languages where it's appropriate.

Not in those where being close to the metal matters.

C++0x introduces a bunch of smart pointers to the standard library (and boost provides them externally for previous versions). What are the advantages of garbage collection over these?

The mere fact that you have to use smart pointerS is enough of a drawback; not only do you need to start decorating various types explicitly, but you must choose which smart pointer types are appropriate, and avoid issues of circular references (in the case of refcounting) and persistence of references (in the case of scope-guarded objects tied to a stack frame); worry about logical ownership hand-off from one smart pointer container to another, etc.

The real power of GC, though, is freedom to use idioms that are simply impractical, or especially, not exception safe, in its absence (see my comment earlier).