13 November 2010
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
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.
Incidentally, there is a language that's literally just C with
classes. They call it Objective C and it's quite elegant. It is also completely different from C++, and much more limited.
- 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).
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.
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.
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.
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.).