Smart pointers aren't free, memory or otherwise.

The syntactic overhead of declaring smart pointers is one. Say what you want, but the verbosity of these declarations is quickly tiring, and ergonomics is relevant. typedef's help, but that leads to the next bit, which is that smart pointers are leaky abstractions in the sense that they are never going to be directly interchangeable with a regular C++ pointer. So the abstraction breaks down (if only a little) anytime you need one.

Destruction and RAII have benefits that it's harder to leak memory, but they force you into awkward contortions where you may potentially need more copies than usual, and because copying is an O(n) process in some instances, this can result in the contortions changing the complexity characteristics of data structures or algorithms. Move semantics can alleviate this greatly, however, and they are a welcome addition, as are many other things in C++11 (moves, constexpr, for-each, better enumerations, lambdas, and auto are all very welcome.)

And finally: the massive, unadultered proliferation of reference types quickly becomes an incredible load intellectually. As a programmer, you likely don't care a ton about the sharing semantics of any individual object and whether it's smart or unique or whatever - that is something that can be done automatically with no intervention on your part.

If it turns out you do care about these things greatly, because they are important to your actual task at hand, it is likely C++ may be a good choice. I have written C++ on the job, and have gone from nightmarish code to much nicer code, and it is a suitable tool for many issues.

The counterargument, which is valid too I think, is that sharing semantics form an important part of an API - you can determine whether or not you own a object because it's unique, or whether you should be careful, as it's shared. But this of course a benefit that extends to any typed data, in any typed language (that's worth its salt.)

But people who throw around "just use a smart_ptr and you're like, just as good as Java, obviously" aren't really helping. There's lots of valid points for both sides.

Again why schlep all that around?

Because in a vast majority of cases, it's irrelevant and your time and money is probably just as well spent somewhere else.

The world is turning back to native code, for good reason.

What indications do you have for this? I suppose iOS is a good case example, for one. But the massive amount of web property and the needs of those institutions alone for example, shows that while the world does need native code, it's not turning back to it with reckless abandon.

Futhermore, native code and garbage collection have nothing to do with each other. And the JVM isn't anywhere near the best example: Java having a very heavy per-object overhead (something like 5-7 words per object for heap metadata) doesn't help memory benchmarks in the slightest, although the JVM does have impressive compilation facilities.

But if you want a much better baseline, compare to something like LuaJIT, that gets comparably close to even C++ with only a tiny memory footprint, or compare it to something like GHC where the collector is remarkably robust, and the per-object overhead can be significantly decreased (as all objects instead only have 1 word overhead, and unlike a language like Java, you can totally unpack structures of composite, non-primitive types, meaning new data types can come 'totally free.')