smart_pointers in C++ are dead slow compared to Java's GCed pointers. And full featured GCs for C++ are unicorns. There are a few, but noone actually uses them in production, except a few experimental language runtimes.
I assume you mean ref counted smart pointers, not all smart pointers are ref counted.
Java's pointer might be faster than shared_ptr. But, in Java, all objects are held by pointers. C++ gives you more options. It's not like we're going "Damn, I just can't figure out the ownership here. I'll just use shared_ptr and be done with it" every day. In my experience, usage of shared_ptr is quite limited.
It is definitely going to change at some time, IBM already has a prototype of JVM supporting object packing and fine-grained alignment control.
shared_ptr use is limited because shared_ptr is slow and people learned to avoid it at all cost. But having to think about ownership influences design choices and often makes things more complex and less performant that needed (e.g. it often forces to copy objects instead to just pass a pointer).
Thinking about ownership is something that is natural for C++ programmers and will naturally affect design choices. We (C++ programmers) don't avoid shared_ptr at all costs and the primary reason for avoid it is because it muddles ownership semantics. In other words: if a magical zero-cost shared_ptr implementation appeared, we wouldn't start using it everywhere.
You can keep extolling the virtues of Java performance, but fact remains that Java doesn't see much use in areas where performance is critical. It doesn't mean Java doesn't have a use, it's just not there.
As of Java being not-performant enough: that's why Java is used as one of the most popular language for implementation of modern NoSQL databases systems. Everyone knows performance doesn't matter in databases. ;)
unique_ptr, the default smart pointer in C++ is no slower than direct pointer access. If you require data sharing, then shared_ptr offers you that feature at the cost of reference counting.
unique_ptr is not a replacement for Java's GC. It simply doesn't do the same. shared_ptr is much closer, but at the cost of reference counting, which, if you start using it excessively, is much higher than cost of Java GC.
I agree that if your memory management is dead simple and you are fine with using only unique_ptr everywhere, C++ solution is superior. You obviously don't need GC, so why pay for it. Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls.
However, there are some domains where GC enables completely different ways of programming. E.g. lockless concurrency / immutable structures / functional programming etc. Poor shared_ptr performance and scalability is prohibitive in those areas.
> Probably C would do just as fine, assuming you have some static analysis tool to find all the forgotten free calls.
I don't believe such a static analysis tool can exist without being a different language (e.g. Cyclone). There just isn't enough information about ownership semantics in C's type system.
In cases, where unique_ptr is enough, ownership is simple and statically pairing all mallocs with frees is easy. The whole problem with memory management is sharing ownership. Then things start getting hairy.
