I really dislike this article to be honest. Here are a few specifics
IDEs are horrible, yes. I agree on that point. But they’re getting better.
Headers might seem counterproductive, but you don’t write C++ the same way you write business apps in C#, where you just churn out massive amounts of code. Templates in header files can’t really be worked around by design. It’s not perfect, but there are ways around it (not saying they’re pretty). C# also has a “preprocessor” with #ifdefs, and being used for low level things, you really do need to have conditional compilation at least in some places in C++. Also, I don’t understand why you’re bashing on namespaces, since C# uses them as well. You can import namespaces in C#, much like you can do so in C++, and you can do it at a local scope as well, which is something C# doesn’t allow you to do.
Compilers are difficult to implement, and having multiple vendors will lead to inconsistencies, especially in new features like C++14. Also the StackOverflow link you post says something completely different than what you say in your blog post. Portability in C# doesn’t really exist, unless you restrict yourself to the not-so-buggy subset of Mono and drop a few nice frameworks like WPF. If you’re doing platform specific things in C++, of course it’s going to be platform specific. That’s the whole point of the language, that you can touch the actual machine your software is running on. Also not to mention there are large number of cross-platform portable libraries like POCO, Qt, Boost, etc.
“It’s a counterproductive language” is very inaccurate. Most of the time I feel more productive in C++ than in C#, but it depends on the project. What you experienced is that you can’t program in C++ without learning the language first. I’m not saying it’s newbie friendly, or that it’s easy, but if taught the proper way it can be very accessible. I know of a lot of novice programmers who are quite happy programming in C++ (even having known C# and Java before), just because a lot of things are more elegant and direct in C++.
You bash on std::chrono, yet the reason why DateTime is so easy is because it’s put in the allmighty global System namespace. Also you can either have std::chrono autocompleted, or use using std::chrono in a local scope and be done with it. The name of highresolutionclock is debatable, but since there are multiple clocks available (based on the type you actually need), I’d say it’s a fair decision to name it based on what it does.
Quoting “And there’s no reason why the C# version would be any slower than the C++ code, if you don’t mind the JIT work.”. Not in this particular case, but LINQ in general leads to some horribly inefficient code due to the way it works, and a lot of people just use it without thinking twice and produce such code. Sure, the LINQ version has one less parameter, and there are actually libraries that provide STL-like functionality on collections directly, instead of using iterators. I’m not arguing about that. Though the lambda syntax for C# is shorter because C++ by design absolutely has to have the capture list.
Lastly, you mention that shared/uniqueptr makes code hard to read. It does make the code a little bit more verbose, but it does help readability in the sense that you have a much better idea of what’s going on. If I see a uniqueptr somewhere, I instantly know a lot more than if there was just a *, or in case of C# nothing.
I don’t want to sound as if I’m fanatically defending C++, since it’s a language of many flaws. But the points you mentioned seem wrong, and if I’m to guess, caused by the fact that you started programming C++ before you had a deeper understanding of the language, which can be a source of frustration, yes. It’s not easy to learn C++, and it does take quite a bit of time to get good using the language. On the other hand, there aren’t that many contestants, and C# definitely isn’t one of them in the areas where C++ should be/is used and/or required.
I’m surprised templates get such a small mention. The other issues could conceivably be fixed with tooling/library changes, but no amount of library changes will fix the fact that the closest thing C++ has to generic types are a bizzarro macro-instantiation mess where a common implementation technique is to intentionally cause compile errors because the compiler will just try another template instead.
Also C++ programs are mostly huge because, y'know, glorified macros.
It is what it is. There are many alternatives, C, Java, C#, Objective C. Some are lower level, higher level, more or less portable, slower and usually mot faster. None have exactly the same trade offs that C++ has, speed, portability, power. By definition all general purpose languages have to faulter somewhere.
I can’t believe the words “security” and “secure” do not appear anywhere in this post. C++’s insecurity is its most significant fault IMO.
I really dislike this article to be honest. Here are a few specifics
IDEs are horrible, yes. I agree on that point. But they’re getting better.
Headers might seem counterproductive, but you don’t write C++ the same way you write business apps in C#, where you just churn out massive amounts of code. Templates in header files can’t really be worked around by design. It’s not perfect, but there are ways around it (not saying they’re pretty). C# also has a “preprocessor” with #ifdefs, and being used for low level things, you really do need to have conditional compilation at least in some places in C++. Also, I don’t understand why you’re bashing on namespaces, since C# uses them as well. You can import namespaces in C#, much like you can do so in C++, and you can do it at a local scope as well, which is something C# doesn’t allow you to do.
Compilers are difficult to implement, and having multiple vendors will lead to inconsistencies, especially in new features like C++14. Also the StackOverflow link you post says something completely different than what you say in your blog post. Portability in C# doesn’t really exist, unless you restrict yourself to the not-so-buggy subset of Mono and drop a few nice frameworks like WPF. If you’re doing platform specific things in C++, of course it’s going to be platform specific. That’s the whole point of the language, that you can touch the actual machine your software is running on. Also not to mention there are large number of cross-platform portable libraries like POCO, Qt, Boost, etc.
“It’s a counterproductive language” is very inaccurate. Most of the time I feel more productive in C++ than in C#, but it depends on the project. What you experienced is that you can’t program in C++ without learning the language first. I’m not saying it’s newbie friendly, or that it’s easy, but if taught the proper way it can be very accessible. I know of a lot of novice programmers who are quite happy programming in C++ (even having known C# and Java before), just because a lot of things are more elegant and direct in C++.
You bash on std::chrono, yet the reason why DateTime is so easy is because it’s put in the allmighty global System namespace. Also you can either have std::chrono autocompleted, or use
using std::chronoin a local scope and be done with it. The name of highresolutionclock is debatable, but since there are multiple clocks available (based on the type you actually need), I’d say it’s a fair decision to name it based on what it does.Quoting “And there’s no reason why the C# version would be any slower than the C++ code, if you don’t mind the JIT work.”. Not in this particular case, but LINQ in general leads to some horribly inefficient code due to the way it works, and a lot of people just use it without thinking twice and produce such code. Sure, the LINQ version has one less parameter, and there are actually libraries that provide STL-like functionality on collections directly, instead of using iterators. I’m not arguing about that. Though the lambda syntax for C# is shorter because C++ by design absolutely has to have the capture list.
Lastly, you mention that shared/uniqueptr makes code hard to read. It does make the code a little bit more verbose, but it does help readability in the sense that you have a much better idea of what’s going on. If I see a uniqueptr somewhere, I instantly know a lot more than if there was just a *, or in case of C# nothing.
I don’t want to sound as if I’m fanatically defending C++, since it’s a language of many flaws. But the points you mentioned seem wrong, and if I’m to guess, caused by the fact that you started programming C++ before you had a deeper understanding of the language, which can be a source of frustration, yes. It’s not easy to learn C++, and it does take quite a bit of time to get good using the language. On the other hand, there aren’t that many contestants, and C# definitely isn’t one of them in the areas where C++ should be/is used and/or required.
I’m surprised templates get such a small mention. The other issues could conceivably be fixed with tooling/library changes, but no amount of library changes will fix the fact that the closest thing C++ has to generic types are a bizzarro macro-instantiation mess where a common implementation technique is to intentionally cause compile errors because the compiler will just try another template instead.
Also C++ programs are mostly huge because, y'know, glorified macros.
Templates are one of the relatively good parts. Intentional compiler errors are a good way to do negated types.
It is what it is. There are many alternatives, C, Java, C#, Objective C. Some are lower level, higher level, more or less portable, slower and usually mot faster. None have exactly the same trade offs that C++ has, speed, portability, power. By definition all general purpose languages have to faulter somewhere.