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++?
And this highlights the difference between C and C++, and better specified/more tightly defined languages.
Two C programmers will ask, "What will this program do?"
Two Ada programmers will ask, "Will this program compile?" Because if it does compile, they both know (and agree on) exactly what the legal program will do.
Not quite, it is in fact undefined.
C++ is the post-increment operator, it increments the variable, but then returns the original value. Therefore, since C started out as 0x11, C++ will evaluate to 0x11 while modifying C to be 0x12 as a aside effect.
Therefore, if you were > optimistic you could try to claim that "C++ < C", expecting the operations to be evaluated left-to-right and thus be evaluated as "0x11 < 0x12". However, C++ doesn't specify the evaluation order of operators, which means that "C" might end up being evaluated before "C++", in which case the comparison would be evaluated as "0x11 < 0x11" instead. The only thing you can be sure of is that C++ will NOT be greater than C.
Basically, as a rule of thumb you should never modify a variable within a line of code if the value of that variable will matter anywhere else within that same line. http://en.cppreference.com/w/c... - discusses undefined behavior halfway down the page.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
It also has good features, many of which provide you with an alternative to the bad features of C.
Constructors/destructors (RAII) > manual initialization/deinitialization.
Smart Pointers (made possible by RAII) > raw pointers
Polymorphism > function pointers
Templates > macros
If you are subscribing to a streaming movie service and you have the choice between netflix and a site that only allows you to watch "Armageddon (1998)", does it make sense to choose the latter because netflix has more bad movies? No of course not, because you don't have to watch the bad movies on netflix, and you can even choose only to watch movies better than Armageddon.
C++ is netflix. Nobody watches all the movies. Everyone watches the movies that are good from their point of view (even though many of those people are just wrong).
In exchange for manual memory allocation, C++ gives you automatic memory allocation: lots of it.
Nonsense. You don't get memory allocation unless you ask for it.
When resources are scarce (eg. IOT devices) this overhead can be a show stopper.
You're misinformed. With C++11 move semantics, you can have both safe, automatic ownership management, and no unnecessary dynamic allocation. Most of my work is done in a very constrained environment, where I have only a handful of pages of heap... or in some cases none at all. C++ is awesome for such environments.
Something that C++ advocates seem to ignore there is no free lunch.
No one is claiming that there is. What there is, is the opportunity to delegate tedious and error-prone due diligence that C programmers have to do themselves to the compiler. For example, you know all those functions that have comments describing whether the returned data structure's contents are owned by the caller or the library? In C++ you can write the function so that it's impossible for the caller to avoid taking ownership when that's what you want, or so that it's impossible for the caller to believe it has ownership when the library is retaining it. If the caller gets it wrong, the compiler will flag the error. That's one example, there are many, many more. C++ enables you to have buffers and strings that do automatic bounds checking... or even to write code such that potential bounds violations are flagged by the compiler, making run-times bounds checks provably unnecessary.
There's no magic here, just language constructs that allow you to accurately specify the semantics you want, which the compiler can enforce.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
C++ is much better than C. It's much greater expressiveness makes it easy to clearly formulate what you are doing, and in far fewer lines of code too. Exceptions free you from all that tedious boilerplate, where every function call basically expands into three lines: error=function();if (error) handle_error (error);. RAII makes resource handling painless. It's massively more powerful standard library provide instant access to lots of useful datastructures and algorithms, and unlike C it's all typesafe too.
Is it hard to use? Hardly. I find C hard to use - just imagine having to write an application that uses strings, it'll be one giant mass of mallocs, strcats, strcpys, frees (don't forget any!), and will invariably end in buffer overflows and lost memory. Oh, and it will probably have a whole bunch of gotos for what they laughingly call 'resource management', Dijkstra's 1968 paper notwithstanding.
Do I disagree with all the criticism, then? No - but the horror stories that get posted here do tend to be worst possible cases, which pop up once in a very long while, rather than the daily occurrences some people make them out to be. It's been... I don't know, half a decade or so? since I last saw one of those horrifying template errors - and it's not for lack of templates in my code. It's not really a hard language either - sure, you _can_ write unreadable statements, but you can do that in any language so that doesn't mean much. It also gives you the tools to write much, much clearer code.
I always roll my eyes when people mention needing a 'cut-down C++'. That's lack of understanding, usually mixed with a liberal dose of unwarranted fear, and better advise would be "use common sense". For example, there is nothing wrong with overloading operators, but common sense indicates one should not change the meaning of those operators. Having your own number-like class is fine (for example, for complex numbers, bignums, money, whatever), and overloading operators for it is an excellent idea. Using operator+ to paint a widget or retrieve data from a database - maybe not so much.
So, yeah, C++ is an amazing language. Hmm, that makes me wonder if there will be an article on Medium now, revealing that someone on Slashdot just said that. I don't know that website, maybe they are not into clickbait so much...
C++ done right is do vastly different from C that debating which language is better is beyond silly. This goes threefold if you look at C++14 programmed with the GSL - the right way to do C++ these days.
In a nutshell C is assembler 2.0 and C++ is assembler 3.0. C++ has massive inner api advantages over C that C tries to compensate for with libs such as boost.
Yet build with C++ without knowing what you are doing and of course you'll produce bad software. With C you simply won't get anywhere.
Wether you use one or the other these days is often a matter of personal preference more than anything else. C++ has massive ready-made power with the responsibilty that comes with it. Any programmer looking at these PLs will see the difference and adapt his style of coding accordingly.
We suffer more in our imagination than in reality. - Seneca
Just the other way around: it happened because it was checking, and the additional acceleration of Ariane 5 caused an overflow. Without checking everything would have been fine.