Don’t you think the same is true in C++? Given a class C, is it intended to be used like this:

C c;

Or like this:

C *p = new C;

If you attempt to use RAII by providing a class like C to be declared on the stack, then anyone is free to abuse it by allocating a C on the heap (and hopefully deleting it again at some point), and thus they lose the exception-safe cleanup capability. A basic principle of C++ is that there is no way to stop this.

Yes, it’s true that in C# it is very easy to forget to put a using statement in. So I tend to use the Scheme-style approach of a “with-whatever” method:

WithOpenFile(filePath, file => 
{
    // use file in here.
});

The WithOpenFile method is equivalent to a RAII wrapper class around a file handle, except that it cannot be abused. So it’s actually more robust than the C++ wrapper-class technique. (With C++1x lambdas this is of course now going to be possible in C++ very soon).

On the downside, it’s also less flexible because you can’t embed it inside another object and so associate their lifetimes (C# is severely lacking in language support there anyway).

And when you factor in the “multi core crisis” GC is even more vastly cheap than ref-counting. GC can pipeline its work into background threads, while ref-counting adds a lot of interlocking.

It’s ironic, and it goes against all the “folklore”, but it has to be accepted that C++‘s low-level memory model approach is actually the more inefficient way to do things in very many (probably most) applications.

Consider that a reference counter has to be updated every time a reference is created or deleted. If a smart pointer points to object a, and you set it to point to b instead, you have to update the reference counters for both objects. And every update has to be done atomically to ensure thread safety as well. That makes it still more costly. When you add it up like that, it’s actually quite a few CPU cycles that are thrown away updating reference counters.

By comparison, a garbage collector doesn’t have to do anything when references are created, modified or destroyed. It only has to step in when the heap has been filled so much that a memory allocation fails. Once that happens, it has to traverse the graph of live objects, marking each as in use. All dead (nonreachable) objects are never even touched by the GC; so they’re effectively free. Traversing this graph does take a bit of time, as does the heap compaction that typically follows. But because it happens so rarely compared to ref counting, it’s still vastly cheaper overall.

Didn’t know that garbage collectors were less resource-intensive than shared_ptrs; I thought they were about the same, since they did about the same thing.