Any seasoned developer, C++ or otherwise, will know that squirlly brackets have never killed anyone, object oriented design isn't all that difficult to understand, and not every exception has to be trapped and handled a special way.
These same seasoned developers will also know that while performance is important, it's less of a priority than maintaining some other disciplines of software design. An application that runs very quickly, but crashes often, is going to be less embraced than an application that runs marginally slower and is more stable.
These same seasoned developers will also know that while performance is important, it's less of a priority than maintaining some other disciplines of software design. An application that runs very quickly, but crashes often, is going to be less embraced than an application that runs marginally slower and is more stable.
Very true!
Well, there is such a thing as managed C++, so it's always possible that C++ as a language might still be able to create faster code (or at least comparable code) when that future occurs. Perhaps a more precise argument would be to compare managed vs. unmanaged.
IMO managed C++ is useless. It's like a version of C++ that's hacked to compile to .net - not only is it harder to use than plain C++, but it's just as slow as C#, so it's pointless (compared to C#).
Some may disagree with me on this, but I've found that good performance isn't really measured in clock cycles. It's measured in "acceptable usability". What defines acceptable usability differs from application to application.
Exactly. And for games, guess what acceptable usability is? For me it's 60 FPS+ on the target hardware, so if your game is simple, languages like C# should work fine. If it's very complex and uses advanced rendering techniques for special effects, highly detailed AI x 100, etc., C# may not be fast enough.