The C++ bashing season is back

Proggit fame

Proggit, the programming section of reddit.com is probably the most popular place for general programming discussion these days. Dozens of topics are raised every day and the more popular can easily generate hundreds of comments in just a few hours.

Traditionally, Proggit was considered by many to be a snub place where language zealots reside and advice everyone to learn Haskell and Lisp. IMHO this isn't the right impression. Perhaps these languages get more Proggit share than their actual use, but this is far from saying that "real" issues are not being discussed there. Like bashing C++.

Here's a short collection of recent discussions, with the original articles that started them:

A redditor asked two months ago whether he's crazy for liking C++. Here's a very nice quote from one of the answers:

You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :)

Peter Seibel, the author of Coders at Work asked most of the star programmers he interviewed about C++, got many negative opinions and very few positive ones (and even those, quite reserved). Proggit discussion.

And of course, there's the famous post made by Linus Torvalds in the Git mailing list, meanly bashing C++. Proggit had many threads on the topic, but this behemoth of almost 1000 comments is probably the most notable. It was discussed again a few weeks ago, with the same general spirits.

So why is C++ so bad?

A fellow Israeli named Yossi Kreinin compiled a whole website dedicated to the deficiencies of C++: the C++ FQA - "Frequently Questioned Answers". A word of warning - if you have to write a large amount of C++ code soon, don't read the FQA - you may get really bummed.

The FQA has also been discussed quite a few times, and although at times it is a bit too harsh, overall the observations made there are correct. Very few corrections have been made over the years it exists. C++ does have many flaws.

My personal contribution: the worst thing about C++, IMHO, it's that it's extremely hard to understand code written by others. Here, I said it. Not the templates, not the exceptions, not memory management and not diamond inheritance. Yes, all these features aren't perfect and could have been designed in a better way, but they're manageable. Reading the code of others is the biggest problem. And since C++ applications are rarely a one-man-job (much less than in the more dynamic and hence productive languages), reading code is an important part of a C++ programmer's job, and reading C++ code is darn hard. Wanna read C++ code written by great programmers? Try to read the source of boost, or Andei Alexandrescu's code - good luck! Wanna read C++ code written by poor programmers? Don't even bother.

Linus Torvalds, in his tirade against C++ explicitly says that he uses C to avoid C++ code contributions from other people (well, he used stronger words...)

Code readability is one of the major reasons I prefer Python over Perl. Perl is a mostly a good language, but Perl code written by others tends to be unreadable. Luckily, there are great alternatives to Perl - Python and Ruby for example.

With C++ the problem is deeper. Yes, it's complex and it allows to write unreadable code, but this by itself doesn't make it a bad language. Contrary to Perl, however, there is no real alternative to C++.

But what's the alternative, C?

And herein lies the great dilemma. Yes, C++ is needed less these days. Many applications (oh, lucky souls!) can get by using Python, Ruby or something of the sort. Many applications (especially for Windows) get written in C#. But for some kinds of applications it seems that the only viable options are still C and C++. There are many examples, really, but take something popular - µTorrent - an amazing amount of functionality, useful GUI, fast and slim, comes as a standalone .exe weighing less thank 300 KB. µTorrent is written in C++, and you could never, ever, make it so fast and small using any other language. C++ and C are the only options you have here.

Another example is something like Photoshop - can you even imagine writing an application of such size, and yet top-notch performance, that runs on several platforms, in anything other than C or C++? Firefox is yet another example, written in C++. Web servers are usually written in C. When you have to squeeze absolutely the most performance out of an application, C and C++ remain the only really viable choices. No matter how much optimization IQ goes into the JVM, C and C++ allow you to write code that is "close to the metal" and hence for the critical, hand-optimized code sections, they will certainly be faster.

And the big problem, the greatest dilemma comes when you have to choose between the two.

C is much less reviled than C++, and rightly so. The language is much simpler, and hence has much less itches to scratch. And reading C code is surely easier than reading C++ code.

But who will start a new project in C these days, unless it's an OS kernel, has to run on an embedded device, or Linus Torvalds is in the team?

After all, you can take C++ and write it as a better C. Isn't it a shame to reimplement all those conveniences of C++ with plain C? OK, let's just use those nice string and vector classes instead of writing our own. And, oh, this ADT we have here is better written as a class. Et cetera, and very quickly you start hacking partial template specializations and pondering the dynamic casts of your multiple inheritance ridden class hierarchies.

Where do you stop? Which subset of C++ do you pick and stick to it to really make it a "better C"? Let me paste that quote once more:

You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :)

For someone the good parts of C++ are exceptions and RAII. For another it's templates and STL containers. Each one is picking his own subset, and no one seems to agree whose subset is better/safer/more comprehensible.

This is how all religious wars start.

Personal experience

A few years ago my day job was C++ coding. I found myself in the same dilemma as the one described above, and have actually re-implemented a couple of C applications in C++. I was satisfied with the process overall, but started experiencing the fangs of fear from the language. This came to a culmination when I perused Modern C++ Design by Andrei Alexandrescu - I realized I'll probably never be smart enough to really understand C++ with all its quirks and dark corners.

Somewhat later I had the pleasant experience of writing C++ code with Qt. Based on hearsay, Qt is quite complicated and hackish inside, but what it presents to the outside is pure delight in terms of API design. Writing C++ code with Qt was fun and very productive.

Since then I didn't get to write C++ much. I wrote C for embedded devices where C was the only choice, so I didn't have the dilemma. I wrote a simple Windows GUI application using C++ and the Win32 API. Since the applications was small, my code didn't get bloated and I enjoyed being able to just create a map of string to vector when I needed it - coding it in C would be much more painful. But mostly I've been using Perl and Python, the latter quite successfully for non-trivial Windows applications with GUIs and networking,

As for the future, I hope not to have to choose. Frankly, I hope not having to use C++ or C for any non-embedded applications. Wherever I'll be able to get by with higher-level languages like Python, I'll take the opportunity with both hands. But if I do face the dilemma, I'll probably pick C++ and will again try to stick to the smallest subset required to complete the job without getting stuck in the complexity quagmire.