Top 5 myths about C++

13 November 2010

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Bjarne Stroustrup

Nothing is perfect; certainly not programming languages. But it's one thing to complain about legitimate issues, and another entirely to go by old misconceptions that could be cleared up with a little research. Due to its prominent status, C++ is often a victim of ignorance, as people think they know things about it just because they keep hearing the name. So let's see a few things people believe about C++ that just aren't true. This isn't purely for fun: programming is hard, and the last thing you want is to limit your options artificially.

Myth #1: C++ is just C with classes

In all honesty, I can't blame people for believing that, as virtually all C++ manuals start by teaching C, as if the "++" part was only an afterthought. But the truth has to be said: C++ is much, much more than its predecessor. Let's see a few other features C++ has over C.

• Input/output streams. No more fearing that a poorly written call to printf() will crash your program, or that a buffer overflow in scanf() will turn into a security nightmare.
• True constants, constant function arguments, inline functions — all of these are excellent opportunities for optimization by the compiler. The latter was actually backported into C99, after being a GCC extension for years. It's that useful.
• Templates. The simple ability to specialize a function over its argument types makes for code that is clearer, safer and faster than if you had to fiddle with pointers. And then there are the truly advanced uses.
• References. Speaking of fiddling with pointers, in C++ you can often avoid it entirely. Ain't that good?
• Exception handling. Speaking of code that's clearer and safer, no modern language is without exception support.
• Namespaces. If you think having to make every function name in your library start with a unique prefix is a problem, this is the solution.
• Operator overloading. Okay, this is a controversial one, but it is a feature, and one few other languages have (Python springs to mind).

Myth #2: C++ is just too complicated

Wait, weren't you just complaining that C++ offers too little over C to be worth the trouble? Make up your mind. Seriously, you can pick and choose which C++ features to use, and what you don't use won't clog up your executable OR your brain.

Myth #3: Manual memory management is hard

Harder than with a garbage-collected language, maybe. But between the rules for variable lifetime and the STL, C++ makes memory management far easier than C. Reference counting is trivial to implement, and true garbage collectors exist if you want to use one.

Myth #4: The STL? But it's slow!

Again, compared to what? People write games in Python and telephony applications in Erlang. Unlike either of those, C++ is at least a compiled language. Rest assured that for most uses the STL will provide more than satisfactory performance. See also myth #1 for other C++ features that can make code faster than equivalent C.

Myth #5: C++ has few libraries

Bwahaha! Do take a look at Boost. Not to mention that any self-respecting C library is designed to be compatible with C++, so it's not an either/or decision. As a plus, libraries you don't need will not take up space on the end user's machine, unlike with massive runtimes such as .NET or the JRE.

A personal anecdote

When I ported Square Shooter to the desktop, C++ was not high on my list; I had only used the language once before, ten years prior, for a less than serious programming project. But the prospect of having the game available as a stand-alone executable file was too tempting. Imagine my surprise when the port turned out to be trivial (barring unavoidable difficulties — I had to learn OpenGL to do it). Especially as the original code was Javascript, a much higher-level language. The resulting code was cleaner, and I was able to do some optimizations that are simply not possible in a dynamic language. Last but not least, the game compiles out of the box on Windows and Linux, without so much as an #ifdef, thus putting to rest another myth, namely that C++ is somehow less portable than e.g. Java.

Of course, choice of programming language depends on many factors. Point is, you should make an informed choice, and not go by hearsay. Hope this helps.

Comments

People who say the STL is slow have never actually done any sort of benchmarking on it. Often, the STL is faster than hand-rolled equivalents, especially in terms of scalability, and the fact that you can create an amazingly complicated, useful, and efficient data structure with a single template invocation which just behaves correctly with a simple API (instead of having to write thousands of lines of code that you have to test and so on) makes it well worth the couple of mostly-irrelevant downsides.

My only complaint about the STL is really more to do with how compilers still can’t do template folding very well, and so tracking down what exactly the compile-time error is with a tiny template parameter mismatch can be a quite aggravating exercise.

fluffy

People who say the STL is slow have never actually done any sort of benchmarking on it.

Heh. I suspected as much. But I really did have a lengthy argument with the authors of Yate, who insisted that they just couldn’t get enough performance out of the STL and had to write their own string class. I was skeptical, of course, but having no experience with high-performance software I couldn’t exactly contradict them.

Felix

Oh, and usually when there’s a legitimate performance issue with STL, it’s because people are using it wrong (passing a large structure by value instead of by reference, using a completely inappropriate structure for their use case, using a crappy hash function, etc.).

fluffy