We've been hearing how small ubiquitous devices and vast web sites have reminded everyone that efficiency and performance really are important in code. All I can say is, yes. And we've also have been hearing that as a result, C++ is coming back! Um, why?
The conventional wisdom ten years ago was that size and speed didn't matter much, since desktop hardware was so big, fast and underutilized. Instead, time to market, maintainability, integration, quality assurance— those were the things to worry about. Code bloat? Inefficient use of hardware resources? Not important.
As someone who did a fair amount of assembly-language programming on really small embedded systems in the 1980s, I could never quite swallow that argument. And because of the time I spent writing assembly-language, I deeply appreciate the C language.
C, not C++.
But if I'm trying to write the fastest, tightest code possible, for a driver or server application or library, I believe that C is still the right language: C, not C++. Why?
The thing about C is that it was designed specifically to balance the need for portability against the need in system programming to be able to understand exactly what your code is doing at a hardware level. It was and remains a brilliant abstraction of processor instructions. All those nasty preprocessor directives are an incredibly effective means of setting different contexts so the same code can run on diverse systems. The language itself is pleasantly terse (minimal typing), which is less important these days when our IDEs support code completion, but I'll tell you, it used to matter a lot, and it's elegant! My main point, though, is that C hits the perfect level of abstraction for system code. It's high enough level that you can read a lot of it fast, and it's low enough level that you can find out exactly what is happening at every step.
Why should you know what's happening at every step? Isn't encapsulation a beautiful thing? Not for system code. If you can afford not to care what your components are doing, use a really powerful scripting language. That's often a good choice for mobile devices, too, because byte-code is a lot more compact than native code and is easily portable.
Now, the C++ aficionados will say, perhaps rightly, that for very large projects with multiple teams, C++ can facilitate inter-team communication. It's more type-safe. You can spell out your contracts more clearly using classes and interfaces.
Well, you can do the same things in C, of course, just by taking care. Most of the shortcuts and short-hands of C++ are just that, and the simplicity of C makes you express your APIs in a very concrete way. C forces you to expose what you're doing, where one of the objectives of a lot of C++ code is to obscure (encapsulate) it. And look, if you're thinking about performance, you have to focus on two things:
-- Am I doing things the most effective way (am I using the right algorithms)?
-- Am I doing things as efficiently as possible (am I avoiding unnecessary steps in my implementation)?
The short-hands and shortcuts of C++ generally make both these factors harder to evaluate.
Also, transparency is particularly valuable in the open-source context, as opposed to the standard corporate model where source-code is kept secret. Even on very large system projects, I believe that the simple clarity of C code makes it the best choice. For instance, say what you will about Linus Torvald's personality, he's a good architect, and Linux remains clean and well factored. It would not be any easier to understand if it were written in C++, and it would likely be much messier under the hood.
Incidentally, I adore Linus' famous rant on this subject in 2007. What a jerk, but he's so right! And he is not alone in having problems with C++. Among its detractors are the likes of Niklaus Wirth ("C++ is an insult to the human brain"), Alan Kay ("I invented the term Object-Oriented, and I can tell you I did not have C++ in mind"), Bertrand Meyer ("There are only two things wrong with C++: the initial concept and the implementation," or "C++ is the only current language making COBOL look good"), and even Donald Knuth ("Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, 'OK, we'll do them both'. So the language is too baroque for my taste").
Now, I know C++ programmers will passionately disagree. Bjarne is every bit as arrogant as Linus, and Microsoft is busy drumming up business for a "modern" C++. I'm just speaking my own experience: object-orientation is good when I don't have to care about what's happening at the machine level. If I have to care, C is the language I choose. Still.
you quote a lot of people saying C++ stinks, but I did not see any specific examples that illustrate their sentiments. And you can code C in visual studio, no?
My opinion, MSFT should create an easy to use native code language, just like it did C#, where the syntax and feature set is similar to C#. The most important improvement over C++ being the programmer does not have to code prototypes in .h files.
Well, I'm currently working on low-level systems programming using mixed C/C++ that involves things like async IO (the actual low-level async IO implementation), and one thing I can say is that it is a PITA. All of my testing tools are written in C#, so I get a 50/50 mix of the two environments.
What I find is that I spend an awful lot of time fudging with low-level issues and gotchas in C/C++ that could have been avoided in C#. If I spend the same amount of time in C# doing the same thing, I can end up spending more time working on the actual high level algorithms etc which in itself results in optimizations.
An extreme example would be assembly vs C#. Yes you can eventually come up with a faster implementation to the same problem but while you try to get the hard-to-debug-and-maintain assembly code working in the 1st place, the C# implementation would long since have been done and you can focus on improving it in other areas, like adding caching algorithms etc that will eventually result in quite performant code.
Also take into consideration that the problems we need to solve are becoming exponentially more complex, and you realize we can't be futzing around in a low-level language trying to solve problems that should not have been there in the 1st place (obscure memory leaks and bugs, fighting with the single-pass compiler because it's too stupid to recognize the definitions a few lines down in the same file, packing issues, calling conventions, header files, nasty STL syntax and usage, confusing compiler error messages, and whole lot more I forgot right now).
@BitFlipper: Yes! This is my experience exactly! C# with .NET beats C++ and C hands down (actually, so does Python) for just getting things working reliably when your whole system doesn't depend on one piece of code. But, when you're writing something that's needs to be as performant as you can possibly make it, either because it's on a critical execution path or because everyone in the world is going to have to rely on it and my have it on their critical paths, then I would much rather use C than C++, or anything else for that matter.
My opinion, MSFT should create an easy to use native code language, just like it did C#, where the syntax and feature set is similar to C#.
Frankly, ANSI C which includes something like stdint.h, Windows.h and a header file to "normalize" warnings (e.g. "X not found - assuming extern function returning int" is stupid. and should be an error not a warning) gets 95% of the way to what you want.
I like C. I don't like C++.
You use a tool to get a job done. C++ doesn't make C obsolete in any way (I get the sense you're complaining that since we don't focus on C we think it doesn't matter... This is not the case.) C++ adds many things to C beyond classes... I'm not sure I understand the problem here. You could also write x86 by hand, if you want go really, really, really native...What's the point?
This debate strikes me as one that has no purpose other than to satisfy an urge to present an opinion (C is better than C++). That's OK. It's fun to geek out.
C is a great language, one that powers a lot of computing today (and tomorrow). C++ is a great language, one that powers a lot of computing today (and tomorrow). Use what makes sense for the task at hand (sometimes, templates can be great, you know that whole genericity thing...).
For some real examples (as opposed to opinions of others), Google's V8 is implemented using a strict subset of C++ (C with abstract data types...). Chakra is implemented with C and C++ (some templates...). If you use both languages to solve a set of computing problems, then where does that leave your argument?
C or C++, go native when it makes sense, both are significantly more high level than machine code... If you need features of C++, then use C++. If C is all you need, then use C. Sometimes, you'll use both (this is the case in systems like Windows, SQL, Office, CLR, JVM, etc...)
Re your quotes... It's certainly the case that very few academics care for C++. In fact, it's cliché to criticize the language in academic PL circles... The fact remains, however, that C++ is a language for engineering, not academic literature. So, whereas I have the utmost respect for folks like Bertrand Meyer, I don't take their commentary seriously, any more than I do somebody stating any opinion as fact simply because it's his or her opinion...
I'm just speaking my own experience: object-orientation is good when I don't have to care about what's happening at the machine level. If I have to care, C is the language I choose. Still.
Not in C++, OO is there, but that doesn't mean you have to use it, and it also doesn't mean you pay anything for having it there and not using it. C++ is far more than just OO.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.