Slashdot Mirror
Someone on Medium Just Said C++ Was Better Than C (medium.com)
Developer David Timothy Strauss is publishing a call to code "straightforward, easy-to-reason-about approaches" -- in an essay titled "Choosing 'Some C++' Over C". (Alternate title: "C++ for Lovers of C."
The problem with just picking C++ is that most criticism of it is legitimate. Whether it's the '90s-era obsession with object orientation and exceptions or the template errors that take up an entire terminal window, there have been -- and remain -- rough edges to C++. But, these rough edges are avoidable, unlike the problems in C that get worse with modern event and library programming.
The opinionated essay calls for "adopting a subset of C++ to smooth out C's rough edges," arguing that C++ offer a better, type-safe approach for event-driven design (as well as destructors to avoid memory allocation leaks). Are there any readers who'd like to weigh in on the advantages of C versus C++?
People who know and like C will continue to use it. Giant legacy projects written in C (like the Linux kernel) will continue to use C, of course. C++ 11, IMO, is not going to convince C programmers to switch. Rather, it's a love letter to existing C++ programmers due to the radical way it transformed the language.
It's still ugly as hell, and has sharp corners that will slice your fingers and toes off if you're not careful (we ARE talking C++ here). Even so, for the first time, using just the core language and libraries (Boost doesn't count), I can completely avoid manual memory management in 99% of the cases, almost like using a garbage collector, but with the advantages of destructors for non-memory resources. Raw pointers are almost a thing of the past, except for some very rare exceptions, and move semantics means your APIs can look like you always wanted them to while still remaining efficient. It's hard to describe how different the language feels pre and post 11.
In my opinion, C++ 11 simply makes C++ far better at creating large, high-performance libraries and applications (in my case, videogames) because of the confidence that robust ref-counted resource management gives you.
Irony: Agile development has too much intertia to be abandoned now.
C++11 and C++14 added some nifty utility features which make the language worth considering as a replacement for C, even if you have no use for writing your own classes or complex templates (the latter being the usual reason why people would use C++).
I've been seeing this C++ vs C comparison for quite a while now, especially on Slashdot. The usual argument is "C++ can do everything that C can, and more, hence it is better than C".
It's a damn stupid argument to make, and the makers should rightfully feel stupid for making it. Say "C++ can do everything C can, and more" is just a different way of saying "C++ has all the gotchas of C, AND MORE".
We write the code to be read by humans, hence anything that adds to the errors made while reading is a *bad* thing, not a good thing. It's fine you add new cognitive traps as long as you are removing existing ones!
When I need a language that is higher level than C, I do not reach for C++ - the alternatives are better. When I don't need anything better than C I use C.
Frankly, I cannot think of a situation in which the lack of features in C cause me to reach for C++. When I want those features I'd reach for Java instead and code the performance critical stuff in C anyway.
The repeated comparisons showing C++ to be a better C is stupid because C++ has all the traps that C has, and adds a whole lot more. When I need the features offered by C++ I can use Java[1] and avoid the pitfalls of C *and* C++.
[1] Depending on circumstances, I'd use Java for large-team dev, Lisp when I'm solving problems solo (hobbying), Tcl+Tk or Python+Tk when I'm doing a once-off make-my-life-simpler GUI script. Mostly I use bash. For daily dev as an embedded guy in safety-critical environments I use C.
I probably won't change to C++ for this case, as having the ability to look at a code snippet in isolation and know exactly what assembly will be generated is an advantage.
I'm a minority race. Save your vitriol for white people.
I first started using C++ back in the 1980's.
I am a huge fan of classes. When C++ was basically a preprocessor for C which introduced the class keyword, I thought it was pretty cool.
When exceptions were introduced to the language I thought C++ was fairly complete as a language. If from there the designers of C++ had addressed the fragile base class problem, lambdas and some form of introspection, I think C++ would have been a fantastic language.
Instead, we got templates. I'm not a fan of templates.
And when we got the standard template library, I thought someone was smoking crack. Using the left shift and right shift operators to mean "input" and "output"? Really? Really?!?
When I write C++ I try to stick to using a subset of C++ which includes classes and exceptions. I use templates sparingly, only when they are really needed, and I refuse to use the C++ left-shift and right-shift operators. (I really feel like the person who designed that thought "how cool; we can override a shift operator to mean input and output!" But just because you can doesn't mean you should, and now we're stuck with this bit of syntactic bit of bullshit.
We're finally getting around to lambdas, though too late: Apple has already wedged blocks into a non-standard extension. And I'm not holding my breath on introspection or on fixing the fragile base class problem simply because the run-time implementation recommendation for classes way back in the late 1980's has become a baked in de-facto feature. (Sadly it would have been relatively easy to solve by introducing link-time assignment of the indexes in the virtual table pointer; that way, as the base class is recompiled the index references for the methods in the virtual table could be reassigned at link time. This also solves fragile access to public class fields; simply replace them with a standard getter and setter method which is accessed via the virtual table.)