A plea for C++

I'm writing this in reaction to some of the comments I've read
on Slashdot about the review of Scott Meyer's "Effective
C++". As soon as I had read the title of the book being
reviewed, I knew there was going to be some gratuitous and,
forgive me, ignorant, C++ bashing. And there was.

I found most of the criticisms against C++ to be as well-founded
and valuable as the usual comp.*.advocacy fodder. Understand me,
I'm not saying C++ is a perfect language that can't possibly be
criticized. Stroustrup himself willfully acknowledges it
isn't. I do say, however, that most people who rant on with
arguments like "it's bloated and induces code bloat", "it's
ill-design from the start", "Java is better", "it's too
complicated" etc... usually lack real insight of they're talking
about, and are just displaying epidermic reaction.

By some strange coincidence, there was an equally inspiring post
on fr.comp.lang.c++, by someone who was complaining about how C
(not C++, plain old C) was an absurdity, mainly because some
operators (like ++ and --) have side-effects, and therefore it
is possible to write expressions which have an undefined
behavior (like in a[i] = i++).

The person who posted this "enlightening" article claimed to be
a COBOL and Pascal programmer, and no, it wasn't a troll.
From my point of view, this article stemmed from the same scheme
of thinking that most of C++ bashing does, which is "It's
more complicated than what I know and use, so it's bad".

There are two points I wish to address here : "C++ is badly
designed", and "C++ is too complicated".

"C++ is badly designed", aka "Java is better"

If you think so, you may first want to read Marshall Cline's C++
FAQ Lite, and Bjarne Stroustrup's "The Design and Evolution of
C++". At least you will have a better chance of understanding why
things are the way they are, and what led to it.

There are a couple of things to consider here. First, C++ wasn't
the design of Stroustrup's alone, and he never imposed anything,
because even if he would have wanted to, he couldn't have done
so. All the points that are now part of the recently established
standard were discussed at length by the C++ commitee. If you
ask BJ why there are no threads in C++, or why there is no
Garbage Collection, his answer is "because we didn't find a way
to make it right", that is, either to provide an API that would
be satisfactory for everyone, or to do it without making
compilers insanely difficult to write, or to do it without
imposing a performance hit, or some combination of
those. Contrast this with James Gosling's answers to similar
questions, which are more along the lines of "because it's
cool", and the fact that Java's thread API underwent serious
changes shortly after being introduced.

Other counter-examples may be found with Ada and Eiffel, two
languages which are supposed to have the cleanest designs, and
yet have acheived very limited success in the industry.

I don't know of any other language which was designed the same
way, that is, with the end-user in mind, and by a voting
commitee in which no one had "the final word". There aren't too
many other languages either where, for each features, the
designers are able to explain why they chose to include or
reject it. You may not agree with their reasoning, but at least
there was one, and more importantly a collegial one, by people
who were actually using the language in very real situations.

"C++ is too complicated"

C++ is complicated, there couldn't possibly be a single
question about that. A very trivial, yet in my opinion
revealing, fact : Kernighan & Ritchie's "The C Programming
Language", 2nd Ed. is 272 pages long, including the
index. Bjarne Stroustrup's "The C++ Programming Language", 3rd
Ed. is 910 pages long, including the index.

Another one is James Kanze's statement, in one of his posts on
comp.lang.c++.moderated, that after more than 8 years of using
C++ for his daily work, he still has to refer to the Standard's
text from time to time. This comment is fully appreciated when
you know that he attended several meetings of the Committee,
actively participated to the elaboration of the standard, and is
one of the most active contributor of
comp.lang.c++.moderated. That is, he's no sunday programmer.

However, to say that C++ is too complicated, is something
quite arguable. The usual argument is, again, Java, which does
most of what C++ is usual used for, except much more simply. The
key word here is "most of".

To first dispell a too-common misconception, C++ is not an OO
language. Java is. On the other hand, C++ can be an OO
language. That's just one of the programming paradigms it
supports, along with imperative and generic programming, all of
which can be freely mixed together, which indeed adds a lot to
the complexity.

Now even when comparing the OO features of C++ against those of
Java, yes, C++ still is way more complicated. The reason is, as
you can expect from my description of how it was designed, that
C++ follows one rigid principle : you don't have to pay for what
you don't use. Hence the fact that every single feature can or
cannot be used (even if "can be used" sometimes implies "if you
can built it yourself or find a class library which implements
it", GC comes to mind). The most obvious example of this is the
fact that all Java methods are, by default, virtual, while under
C++ you have to explicitely state so.

So I often think as C++ being a flight simulator, and Java being
its "arcade" mode. Simulation is more complicated than arcade,
and if all you want to do is fly from point A to B and see the
scenery below without having to care about the fuel level and
oil pressure, which is the case 80% of the time, then arcade
mode will cut it. But there are times when you really want to
have fine control on the throttle, the flaps, the landing gear
and everything, and this is impossible unless you're playing the
real game.

I still find C++ to be doing a pretty good job at hiding quite a
lot of the ugly details (although certainly not enough) of
everyday OO programming. But still, one may argue that things
don't have to be so complicated. This is, in my opinion, a
complete delusion.

Consider for instance another famous religious war : GUI
vs. CLI. Icons and Menus vs. the shell. Suppose you just want to
copy a file from a folder to another, under the GUI it will be a
simple matter of icon drag and drop. Under the shell, you'll
have to type a relatively complicated command. But if you want
to apply the same command to all C source files older than 2
days in an arborescence of folders, most GUIs simply won't let
you do it in any convenient way. With the shell, it's yet
another command. Even more complicated than the first one, but
still, it can be done, and faster than with anything else.

What I'm trying to prove here is that as soon as you're dealing
with complex concepts, you'll have to do complex things, and
have an extensive and flexible set of words to express
things. A 20 words vocabulary may be enough to order food
and drink in a restaurant, but you won't talk about
philosophy. And OO programming is complex, and so is generic
programming. It's the same old tradeoff between ease of use in a
restricted domain out of which you can't go, or difficulty of
use with an almost infinite range of action.

I'd like to conclude with a little personal illustration of C++
power, and more specifically the STL and generic programming.

I recently encapsulated a C linked-list API in a C++
class. Simply by providing an iterator class for the
encapsulated list, all the non-modifying generic algorithms of
the STL can be used on it. That is, algorithms which were
designed without even the knowledge of existance of this linked
list can be used over it. And this is done without imposing any
overhead, neither in space nor performances, on the user who
hasn't or doesn't want to use the STL.

Now this, indeed, wasn't trivial (at least to me, it would
probably have been to anybody more experienced than me).

But it could be done.

Acknowledgements

I wish to thank the following people for the insight gained from
reading their posts and papers, or simply chatting with them
(which does not mean I agree with them all, nor that they do
agree with me on this subject). Most of the above was stolen
from : Cedric Beust, Alain Miniussi, Colas Nahaboo, Philippe
Kaplan, Jean-Michel Leon, Gabriel Dos Reis, James Kanze.