Someone on Medium Just Said C++ Was Better Than C (medium.com) 315
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++?
Indeed (Score:5, Funny)
Re:Indeed (Score:5, Funny)
#include <stdio.h>
int main(int argc, char **argv) {
int C=0x11;
if(C++ > C) {
printf("C++ is greater than C\n");
} else {
printf("C++ is not greater than C\n");
}
}
$
C++ is not greater than C
Re:Indeed (Score:4, Informative)
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.
Re: (Score:2)
What if you use Ada to write something as complex as a C interpreter ?
Re: (Score:2)
Then you get a valid C interpreter... obviously.
Re: Indeed (Score:5, Funny)
Trick question. There is only one ada programmer.
Re: (Score:2)
The C statement "C++ > C" is not true because post-increment occurs after the statement has been evaluated.
Re: (Score:2)
Thanks for that! I never would have guessed...
Re: (Score:2)
Thanks for that! I never would have guessed...
Actually, you didn't. The expression is undefined because the greater than operator is not a sequence point.
Re: (Score:2)
Yet somehow, the use of ADA did not stop Ariane 501 from exploding half a minute after lift-off.
Re:Indeed (Score:4, Informative)
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.
Re: (Score:3)
This is the reason this entire thread is pointless.
Going all the way back to the seventies, it was a core design decision in the C language not to over-specify the semantics of expression evaluation to the degree that tricky, efficient implementations became impossible on realistic architectures.
So the decision was: we're not going to nai
Re: (Score:2)
Re:Indeed (Score:4, Interesting)
WTF, I have to escape less and greater inside of a code tag?
There are no pointers involved, nor objects.
The whole thing is for some strange reason "undefined".
But actually it is pretty clear, why the C community made it "undefined" is beyond me, well: they did not want to impose a rule. But that is mere stupid.
int s = 1;
int b = 2;
s < b; // true // true ... usually, because here it starts, it is actually undefined, facepalm
s++ < b++
s++ < s++; // ok, here we have a point, obviously "it should be false" but it is undefined, and somehow makes sense to be undefined -- for me it makes no sense, in Java this is false
s++ < s; // undefined in C, false in Java. // the original question // is only undefined because some guy thought, using the same variable in an expression involving ++/-- more than once is problematic. // actually they should simple have defined the behaviour. E.g. evaluate from left to right and be done with it
C++ > C;
Re: (Score:2)
Always actually evaluating left to right is extraordinarily costly --- a lot of the trickery that compilers do to make things fast (CSE, interleaving loads & math, etc) don't work with it.
And always actually having the same behavior as left to right, when not evaluating left to right in actuality, is hard to do and pick up any performance. Not for trivial cases like this, but because you might reach the same actual location in memory multiple ways (e.g. aliasing from pointer traversal).
Re: (Score:2)
s < b; // true // true ... usually, because here it starts, it is actually undefined, facepalm
s++ < b++
That's well-defined. For someone arguing over the technicalities of C you sure don't seem to know the very basic rules.
Re: (Score:2)
It is not defined in which order the left and the right side of the less sign is evaluated.
You should consult the manual of C/C++ - which ever you use - again.
Re: (Score:2)
It is not defined in which order the left and the right side of the less sign is evaluated. You should consult the manual of C/C++ - which ever you use - again.
The order in this case does not matter, which is why it is well defined. The standard calls. It well defined, it is predictable what the outcome will be every time hence it is well defined. The expression 'C++ > C' is not well defined because the outcome cannot be predicted every time.
Re: (Score:2)
Well, at least one person noticed that the original poster was comparing two literal strings...
Undefined behavior (Score:5, Informative)
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... [cppreference.com] - discusses undefined behavior halfway down the page.
Re: (Score:2)
So what you're saying is that not only is C++ not greater than C, but it's not even equal to it!
Re: (Score:2)
Interesting, but as I see it C++ has the bad features from both C and Ada and only have the positive side of allowing object orienting.
However some stuff in C++ is quite confusing and does not make it very readable.
Re:Indeed (Score:5, Informative)
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).
Re: (Score:3, Interesting)
Re: (Score:3)
I don't think you can call yourself a C++ expert and be "totally unable to deal with" a C++ codebase that uses a different subset of C++ than what you would have used.
You can certainly be a C++ expert and be totally unable to deal with a very poorly designed codebase, but that is true for every language (even C).
Maybe there are more experts in the C language, because it is a simpler language and therefore an easier language to become an expert at. I would be totally in favor of using a simpler language for
Re: (Score:2)
there are no movies better than Armageddon.
Re: (Score:2)
Re: (Score:2)
false, it is in fact undefined - see my explanation a few posts below
Re: (Score:2)
Re: (Score:2)
Evaluation? They look like literals to me.
Re: (Score:2)
https://slashdot.org/comments.... [slashdot.org]
Can you not see the quotes?
Re: (Score:2)
Actually, it's undefined behavior.
On most implementations, it is not true that "C++" > "C", but it is true that "C" < "C++".
Re: (Score:2)
char *cpp = "C++";
char *c = "C";
printf("C++ > C => %s\n", (cpp > c ?"yes":"no"));
Kids these days... (Score:3)
Code in assembly, then you can come back to my lawn..
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
So, learn assembly in your free time.
Re: (Score:2)
So, learn assembly in your free time.
It's on my to-do list. I'm currently going through an old compiler book to translate Borland C into modern C and learn Pascal to use the resulting Pascal compiler.
Re: (Score:2)
>> I'm currently going through an old compiler book to translate Borland C into modern C
err... why?
Re: (Score:2)
>> I'm currently going through an old compiler book to translate Borland C into modern C
err... why?
To learn C better. Also to learn how to write compilers. The used — and very obsolete — edition of the book was cheaper than the current edition ($5 vs. $70), and modern C compiler books are very expensive. Once I understand how to write compilers, I'll write a BASIC compiler in Python. I've been translating old BASIC games [atariarchives.org] into Python, which I've never gotten to work on my Commodore 64 as a teenager. Of course, Python extensions are written in C (or Cython).
Keep in mind that I got an A.S. degre
Re: (Score:2)
You know you can load a binary into a debugger and view the assembly code?
There's really not much to basic assembler. You have main memory, registers, and flags. You can move bytes (1, 2, 4, or 8 at a time, usually) between memory and registers. You can do basic arithmetic and bit operations in the registers, and those set the flags. You can make jumps (gotos) based on whether the the flags are set or not. That's pretty much it. The hard part is putting such basic instructions together to accomplish
Re: (Score:2)
You know you can load a binary into a debugger and view the assembly code?
Been there, done that. Commodore 64 in the 1980's and DOS debug in the 1990's.
Re: (Score:2)
No, just reverse engineering existing code wont tell you what you really need to know, which is the theory behind what the programmer was thinking.
Besides, the preprocessor may have been auto-generated with something like lexx/yacc which makes a giant state machine and will just give you a giant headache trying to figure it out from the code.
You need to read up on tokens, lexemes, parse trees and other internal representations, once you understand those, you'll understand the meat and potatoes of a compiler
Re: (Score:2)
Besides, the preprocessor may have been auto-generated with something like lexx/yacc which makes a giant state machine and will just give you a giant headache trying to figure it out from the code.
I got the O'Reilly lexx/yacc book.
You need to read up on tokens, lexemes, parse trees and other internal representations, once you understand those, you'll understand the meat and potatoes of a compiler.
Those subjects are covered in the compiler book, which was previously used as a textbook in the early 1990's.
Also you're probably far better off looking at something like GCC than some old Borland crap.
The code in the compiler book was compiled with Borland C in the late 1980's. I have to modify the code to be ANSI C compliant for GCC to compile without error.
Re: (Score:2)
Chances you will ever use it is basically zero.
Depends on what microcontroller I used on the hardware side. The newer ones have built-in boot loaders and accept C code over USB. The older ones require assembly language to take up less space than BASIC or C.
Re: (Score:3)
It is not worth learning assembly.
You are dead wrong. I wish I had the points to downvote your post.
You are correct that its not worth learning assembly, in order to learn "modern" software development.
What makes learning assembly valuable is that it is the most barebone, lowest level set of instructions that a human can cobble together for a CPU to execute. Every other language involves cobbling together hundreds of CPU instructions which would be magnitudes more inefficient than expressing it in assembler. Because higher level language
Re: (Score:2)
Almost agree to you... but the basis of modern computer architecture is not Turing but von Neumann. However, von Neumann was well aware of Turings work and the fact it described computers on an even more fundamental level.
For a machine to be a computer, it needs to be Turing Complete*. The machine can simulate any single-taped Turing machine. But it doesn't have to adhere that architecture. As long as it can simulate it, it's fine. *: Caveat: limited memory.
The von Neumann architecture tells of a CPU with a
Re: (Score:2)
Me, I'd need a specific goal for that. I always found I could learn a *lot* faster within the structured classroom environment, and with the benefit of face-to-face conversations with people who understand the topic considerably better than I. And taking classes when you have a full time job - well, good luck with scheduling.
Re: (Score:2)
And taking classes when you have a full time job - well, good luck with scheduling.
Depends on how motivated you are. I worked 60+ hours per week as a video game tester, taught Sunday school and took two classes per semester for five years. I even made the college president's list for maintaining a 4.0 GPA in my major. That was made possible by a $3,000 tax credit that George W. signed into law after 9/11 to help people transition into new careers. While I don't work as a programmer, understanding programming help me troubleshoot difficult problems in IT support.
Re: (Score:2)
Did you do any classes on algorithms? If so, was binary search covered?
Re: (Score:2)
Did you do any classes on algorithms?
That was probably under the "Data Structures" course.
If so, was binary search covered?
Binary search for the tree data structure.
Re: (Score:2)
Oh. Did you take any Gen Ed classes, like perhaps legendary literature or folkloric fantasy?
Re: (Score:2)
Oh. Did you take any Gen Ed classes, like perhaps legendary literature or folkloric fantasy?
During my first tour through college, I took a half dozen lit classes (English Lit 1 & 2, American Lit 1 & 2, Women Lit and World Lit) and graduated with A.A. degree in General Education (1994). The only reason I graduated with G.E. instead of English is that the G.E. requirements didn't require a biology lab to dissect a frog. Because I completed an A.A. degree, I was only required to complete the major classes for an A.S. degree and graduated in Computer Programming (2007).
Re: (Score:2)
Coding in assembly is much easier than coding in a high level language and "doing it right".
No idea where this Myth "if you can not do it in assembly you are not a real programmer" comes from.
On the other hand, I pitty those who need to do assembly in 86k and its derivations.
Re: (Score:3)
Moore's law is unlikely to end any time soon - while it's frequently mis-quoted as having something to do with transistor density or speed, the original claim is only that the number of transistors in a dense integrated circuit would double every year (later revised to every two years, and often claimed as 18 months due to being conflated with a prediction out of Intel at about the same time that processing speeds would double that often)
While transistor silicon speeds are indeed plateauing, transistor cou
Re: (Score:2)
Probably not in our lifetimes, if present trends endure. Consider one quark-per-bit???
They both suck! (Score:3)
At some point, the developer community will wake up to just how evil C -syntax- is, and how much it has contributed to bugs and security holes.
Re:They both suck! (Score:4, Funny)
On the other hand, monkeys prefer C, because the programs they generate by jumping on the keyboard have the best chance to compile.
Re: (Score:3)
On the other hand, monkeys prefer C, because the programs they generate by jumping on the keyboard have the best chance to compile.
I think you spelled perl wrong again :-) (hey - it's a feature)
Re: (Score:2)
But PERL is explicitly built on C syntax. QED!
Re: (Score:2)
Re:They both suck! (Score:5, Interesting)
Re: (Score:2)
"=" vs "==", the presence or absence of commas or semicolons that substantially change meaning, the mess that is #include in large systems...
Just look at any "obfusticated C" contest entry for egregious examples!
Sure, you can learn and code around them. But at best that's a risk. And we have plenty of examples where those risks have made it to deployed systems. What was the Apple bug on certificates where a semicolon introduced a significant bug in certificate validation that was there for years?
Re: (Score:2)
"=" vs "==", the presence or absence of commas or semicolons that substantially change meaning, the mess that is #include in large systems...
Those types of bugs are very rare, and #include was solved long ago with #IFNDEF _HEADER_NAME....
Re: (Score:3)
A good compiler will warn you if you use '=' in a test.
Re: (Score:2)
A good compiler will warn you if you use '=' in a test.
... and a better compile will allow you to make it a compile-time fatal error.
Like this:
gcc -O2 -Wall -Wextra -Werror foo.c
Re: (Score:2)
What particularly don't you like about C syntax?
Function declaration syntax is demented, just to pull one thing off the top of a huge stack. Ever tried declaring an array of functions?
I use awk (Score:5, Funny)
enough sed. don't bash me.
This just in! (Score:2)
This just in, slashdot diminishes usefulness of site for a day in same tired April Fools joke they do every year!
One editor was reported saying, "Yes, we've been beating this horse for twenty years now but rumors of the horse's demise many years prior have been grossly exadurated."
Rubbish in Cans (Score:2)
He favors automatic memory cleanup an trashes C for using marcos for it (which is indeed stupid) and favors destructors . But in that case he could just favor C# or Java. Both do the memory cleanup for you.
Also his examples look very cluttered. It looks more like a C++ lover who try to bash C.
If you want to fix C, don't use C++... (Score:2)
[...] "adopting a subset of C to smooth out C's rough edges" [...]
FTFY — A little trick I picked up from John Carmack.
STL != C++ (Score:3)
Seems like his gripe is actually with STL and possibly curl's interface, not C++ per se.
I like C++ (classes, exceptions etc) but generally avoid using STL except possibly for basic things like cout, strings and vectors. STL code becomes unreadable FAST, and quickly turns a simple problem into a giant pain in the ass, especially when debugging.
I know it's April fools, but still ... (Score:3)
Set the handle to send a pointer to the struct. The handle expects a void *, so there’s an implicit cast from the struct’s pointer type to, effectively, nothing.
A void pointer is NOT a pointer to nothing. At least it better not be. :-)
I started off with C (Score:3)
It's my most familiar language, back from when I was learning it on the schoolbus by reading K&R. I would still never choose C over a carefully-selected subset of C++ for a new project. There is just no advantage to keeping things more primitive except when it comes to very specific environments, like traditional Unix kernels. I think templates are very useful in limited doses and far superior than macros, inheritance is somewhat useful to almost any kind of CS problem, and the STL itself is a huge boon to software reliability and interoperability.
Of course, I also have no qualms with Java, so....
I worked on a C++ device driver (Score:5, Interesting)
In the 1990s I worked on a complex device driver for OS/2 for ATM networking (asynchronous transfer mode) [wikipedia.org]. The driver was around 100K lines of C++ code however only a subset of C++ was used. Surprisingly the use of C++ worked out quite well. We had an equivalent driver for Windows NT that was written in C that was over 300K lines of code. The C++ codebase was a lot more reliable and easier to work on, despite all the work that was done to make C++ work in kernel mode under OS/2. The C++ driver actually had more functionality than the C driver and it was faster as well with a smaller binary. Also, as I said, it was a subset of C++, especially in the performance critical code. The driver in question included the entire ATM signalling stack and implemented full LAN emulation support with both Ethernet and Tokenring plus it could emulate multiple networks (ELANs, equivalent to VLANs) simultaneously. When I implemented multiple ELAN support I was afraid it was going to be a nightmare, but due to the way it was architected in C++ I ended up only having to change a few lines of code, changing a pointer to the LANE class to an array of pointers.
For the signalling stack and ILMI [cisco.com] C++ worked out especially well due to the event and message based nature of it and the various state machines. For LAN emulation it made it easy to support both Ethernet and Tokenring by having a few virtual functions in the main LANE class.
There was no exception handling support and none of the more complex C++ features were not used. It used templates but that was also somewhat limited.
Having destructors was also quite nice, making it easy to clean up resources.
Despite being C++, debugging wasn't too bad though at the time the OS/2 kernel debugger basically ran at the assembly level.
If the infrastructure is in place I can certainly see using C++ in the kernel and device drivers.
Re: (Score:2)
If the infrastructure is in place I can certainly see using C++ in the kernel and device drivers.
Its already been done. At least one of the L4 microkernels (Fiasco?) is implemented in C++. You don't lose code efficiency doing it in C++, if you know what you're doing in C++.
Re: (Score:3)
That's the main problem with C++. It is incredibly hard to know what is happening behind the scenes (will this object allocate memory or not?), so one has to be very careful in performance-critical parts.
Its more difficult to know what's happening below the source code level, because C++ is conceptually more abstract than C. But ANSI C is an abstraction as well. Its not like the days of K&R C, where you knew what the parameter passing code looked like in assembler. And C++ being a higher level of code abstraction than C is a good thing. If you know how to code C++, you avoid all the problems with loose pointers, and memory leaks, and human implementation errors prevalent with C.
(will this object allocate memory or not?)
That is a horrible ex
re (Score:2)
well there is a ++ in the name so.....
C vs C++ (Score:3)
Well, duh - it is (Score:4, Informative)
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...
Re: (Score:2)
gcc added something called "cleanup attribute" which is essentially destructors in C++. That replaces "goto" in the case you described. I really hope they will put it in the standard at some point.
Generally I only use a subset of C++ (Score:4, Insightful)
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.)
Silly language debates (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
It's typically not about being *easier* in C++. It's more often about being *safer* while not giving up natively compiled performance. Anyone looking for "easy" and is using C++ is missing the boat.
Re: (Score:2)
Re: (Score:2)
If you avoid static_cast/traditional (C_casts *), and use -Wall -Werror, then C++ is really quite a lot safer.
Re: (Score:2)
Re: (Score:2)
but C++'s bazooka has compiler-enforced safety if you bother to RTFM and follow the best practices.
Lies. There's no such thing as C++ best practices. There's a subset of C++ that your team chose to you. And I seriously doubt you've read the manual [amazon.com].
Re: (Score:2)
The keyboard input is braindead. There are a lot of functions, but they combine the archaic-ness of C with the verbosity of Java. fmt.Scanln() doesn't actually read a line, it reads a word (delimited by spaces). Reader.ReadString('\n') is recommended in the doc
Re:Actually what the guy wrote was (Score:5, Insightful)
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.
Re: (Score:2)
Sure it is.
Ubuntu has migrated to an NT kernel [ubuntu.com], while the commonest Linux distro, Android, is moving to Magenta [googlesource.com].
Re: (Score:2)
I agree. Windows 7 is vastly superior.
It's a throwback to the early 2000s without support for modern hardware support.
Re:Actually what the guy wrote was (Score:5, Informative)
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.
Re:Actually what the guy wrote was (Score:4, Insightful)
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.
Re: Actually what the guy wrote was (Score:2)
Pretty much every listed criticism of c++ is valid, but I still prefer c++ over c for one reason: c++ has constructors and destructors, which means you can automate deallocation of resources using RIAA and smart pointers. In C you must remember to deallocate manually, and sooner or later you *will* mess it up, leaving you with a nasty memory leak or dangling-freed-pointer problem which you will spend much time tracking down and fixing.
Re: (Score:3)
C++ meets or beats C in all but a very few respects. Designated initializers is a really painful and stupidly short sighted omission. C++ has a wealth, even a surplus (see "most vexing parse") of initialization mechanisms, but none of them can do what design initializers do. Unfortunately, when converting C code to C++, this frequently results in maintainability regresses as code has to be converted to rely more on positional parameters... which you hope you have correct, but you don't always, and you hope
Re: (Score:2)
because C++ has all the traps that C has, and adds a whole lot more.
Right, like manual memory management and ubiquitous printfs.
Re: (Score:3)
I found the same thing when I was handed a large project in C++. In this case it was a very complex kernel-level OS/2 device driver. It took me a while to adjust to C++ but once I did I certainly saw the advantages.
With C we're always reinventing the wheel and doing things the hard way. I say this as someone who works on bootloaders and has worked on a lot of device drivers and works close to the hardware. C++ requires more support than C to get basic functionality working, but once it's there a lot of code
Re: (Score:2)
C also has libraries, you know, things like glib for example.