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".
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 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.
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.
Also thanks to Philip Robar for correcting a misformed sentence :-).