Productivity, not language performance, is the key feature.No this is not accurate. It depends on the application domain. For some projects performance is absolutely key. For others not so much.
Also, productivity is what has improved with c++11 in a BIG way. I'll admit though that it's still not quite c# level of productivity but its much better.
I'd prase it even more extreme:
What changed is that C compilers got smarter and smarter, to the point where they can now write assembly as well as better than experts can (when given sensible inputs). Likewise, C++ compilers got smarter and smarter, to the point where they matched outperform C compilers.
Neither assembler programmers nor C programmers will like this, I'm sure. But the stunning truth is that that's just what has observably happened. Take for example this statement from the Nedtrie home page:
That is exactly it. When C++ compilers started taking over, it wasn't because they generated the fastest code. Now because of popularity and investment, they have been tuned to do it.This is true that modern optimizing compilers do a very good job these days. However the biggest gains in performance since c/c++ started are not from optimizing but from the evolution of the computer hardware.
"Moore's law is the observation that over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years. The period often quoted as "18 months" is due to Intel executive David House, who predicted that period for a doubling in chip performance (being a combination of the effect of more transistors and their being faster). "
While this law may not be followed exactly it does show that performance has been doubling nearly every two years, no level of optimizing can do that. So that is the biggest reason, c became affordable over assembly and c++ over c and so on. Even though the modern features of the languages when they were new, cost a performance overhead. The reason people would pay that price some times was for productivity. Speed of execution vs programming productivity.
Today's computers are so fast that most typical desktop application's can easily pay for the languages such as java/c#, in exchange for that extra productivity. However some cannot, or do not want to, due to the project domain calling for absolute speed.
However c++ is being upgraded now. C is still basically the same language as it was in the 80s. ( There is a new standard but it doesn't fundamentally change the language )
This is what c++ now has over c and assembly, and why it competes with c#, modern features have been added and many more are on the way. C# has many modern features and that is a top reason that it is so productive to program with. So now that c++11 is back in the game, expect the competition to heat up even more in the following years as c++ will have frequent updates with lots of new modern features being added.
That's what I was talking about, thank you.
The "^" operator isn't equivalent to a shared_ptr (if it were, you would have a ton of leaks, because shared_ptr's can't cope with circular references, and require the programmer to be able to explicitly choose between them and weak_ptrs...), it's exactly equivalent to C# references!
In windows 8 you can program in c++ however it is an interesting dialect of c++. There are no naked pointers. Instead they have what is really just a shared_ptr operator ^ .
This means there are absolutely no memory leaks in their version of c++. You can do this without using windows 8 if you wish. So you get the best part of C# in c++. It is rather genius I might add. And there is no need for garbage collection, everything is deleted properly. There is no garbage collector, and everything runs very fast.
The dialect you're talking about is called C++/CLI, and it is compiled to MSIL -- the same intermediate "bytecode" language that C# is compiled to, and it runs on the same VM and uses the same Garbage Collector that C# does!
If he's talking Windows8, he's probably talking about C++/CX, which looks basically identical to C++/CLI, except doesn't compile to .NET code, and in C++CX, the ^ hat symbol *is* used to denote something akin to shared_ptr (it uses refcounting), and suffers from the circular reference problem (they introduced WeakReference to deal with this)