Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Do you think that the criticisms in Frequently Questioned Answers are accurate?

share|improve this question

closed as not constructive by Thomas Owens May 19 '13 at 0:43

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

I do not like C++ very much myself (it gets the job done but it is a quite messy language IMO), but I think the FAQ you mention are rather inaccurate and written more as a rant than as a real criticism. I think one should neither worship nor hate a programming language. – Giorgio May 18 '12 at 18:03
The answer is no, because a rant is not a criticism. If you were to read it beginning to end you would notice a lot of circular logic. I wish I could get back the time I wasted on it. – MrFox May 13 '13 at 20:01
up vote 23 down vote accepted

There are good reasons to dislike C++. The complexity, the multitude of poor, broken, or incomplete implementations, the impracticality of adapting it for specialized tasks...

But taking a FAQ, written to aid users who for whatever reason are using it, and twisting that into a vehicle for voicing your own complaints, problems, and prejudices... no matter how valid or justifiable they might be on their own... is just ugly.

To me, it comes across as sour grapes: the author obviously struggled with C++ and has been more than happy to move on to something else, but lacks the confidence in his own convictions to give a fair comparison of its costs and its benefits, or even simply state, "this didn't work for me when I tried to apply it to my problems". Instead, he seems to feel compelled to argue that the satisfaction he failed to attain is not worth trying for, that no grapes could possibly be sweet enough to compensate him for his struggles.

I wouldn't recommend the FQA to anyone, even if I were trying to dissuade them from using C++.

share|improve this answer
+1. While the FQA has some valid criticisms, it's completely drowned out by the confrontational and antagonistic writing. – greyfade Sep 17 '10 at 0:03
+1 Unfortunately, the FQA (while containing many good points and legitimate criticisms) tends to take C++ to task for doing what it's supposed to do. – Michael Kohne May 18 '12 at 18:53
-1, FQA actually taught me something (would you find any mention of the last issue in in a FAQ? -- and the scope of the enlightment on non-accidental problems with a given C++ feature (templates) is really worth a praise in this case) – mlvljr Nov 9 '14 at 7:21

The author obviously hates C++, and apparently doesn't know how to use the language very well. Such criticisms of any topic are rarely worthwhile, and the FQA is no exception.

Randomly picking 17.7 as an example, we see that the author slightly misunderstands the question, and throws in unnecessary vituperation.

Looking at the whole section (about exceptions): The author doesn't really like exceptions. Fine. He does say some good things about them, then that the good things don't apply to C++ exceptions - not bothering to give much in the way of reasons.

The author is flat wrong in 17.3: destructors can call functions that may throw without problem, provided they catch all exceptions thrown and don't try to repropagate one.

In 17.4, the author goes on a rant about smart pointers. It's technically true that you can and often will create a lot of different smart pointer classes from shared_ptr, but they all work in precisely the same way, making the author's further complaints moot.

17.5 and 17.6 basically agree with the FAQ-Lite advice, combined with exhortations not to use C++, and something the author doesn't like about the C++ philosophy.

In other words, there's really nothing you are going to learn about exceptions here, except that there is somebody who doesn't like them who isn't entirely logical.

share|improve this answer

I suppose I should preface this with the fact that years ago, I took part in a long Usenet thread, after the author posted links (and such) to his "FQA" to comp.lang.c++.moderated. It's probable that at least some of my opinion of the FQA is colored to at least some degree by that thread, not based strictly on the content of the FQA itself. Given the frailties of human memory, it's possible that some of what I think of as problems with the FQA are actually based on posts from other people entirely (I do seem to recall Walter Bright seeming to care a lot more about pushing D than being entirely accurate).

With that warning in mind, it's my belief that the author is deliberately disingenuous throughout at large part of the document. Anybody who knew enough to write what he did, also clearly knew enough to realize that much of what he said was misleading if not outright false. Quite a bit takes some obscure corner case that virtaully never arises in real use, and treats it as if nobody could even write a "hello world" without knowing all the gory details. Just for example, I'm pretty sure I remember him talking about the complexities of resolving an overloaded function name and how difficult it could be to know which of a set of overloaded functions would be called for a given set of parameters. The reality, however, is that if you honestly care about this, you're almost certainly misusing overloading to start with; the basic point of overloading functions is to have one name when all the variations are essentially the same anyway.

Some of his other arguments just strike me as wrong-headed and foolish. For one example, he points to the fact that C++ doesn't define an ABI as if it were a major problem. At least to me, this seems silly. Having an ABI so all the languages on a platform can work together seamlessly is really handy. It's harder to find a benefit of a common ABI between, say, my printer, router, and camera, just because all have firmware written in C++.

A great deal of the FQA also seems to mistake the shortcomings of a particular compiler (the g++ of 2007, apparently) for shortcomings of the language itself, and basically insists that since g++ then did some things poorly (e.g., some error messages) that the language needed to change to fix them. In reality, of course, EDG-based compilers did better then, CLang now does so as well, and even g++ has improved at least a little in this regard. Yes, language changes (e.g., concepts) could help improve error messages, but they're neither necessary nor sufficient to do so.

Summary: The FQA is not basically correct arguments hidden behind invective. Most of its basic arguments are fatally flawed. The few actual facts he cites really don't support his arguments, though he has done a fairly reasonable job of making them sound like they might.

For overall accuracy, I'd rate the FQA as being a bit like a weather forecaster who brags at his retirement that he predicted every rainstorm in the area with perfect accuracy for over 30 years -- carefully ignoring the fact that he did so by predicting rain each and every day for that entire time. You can find a viewpoint that justifies claiming it's perfectly accurate if you want to badly enough -- but if you look at it overall, the record for accuracy is dismal -- it's wrong far more often than right.

share|improve this answer

I'd consider the FQA Frequently Questioned Answers dangerous for a newbie, while it certainly points out some interesting technical points for a more experienced C++ programmer.

The whole approach the author takes is somewhat crooked: On the surface, he makes his text look as the real C++ FAQ -- the more hands-on, more practical, more grounded information by someone who really knows from practical experience. And he consistently uses his "summary" of the original FAQ to asperse this information source and let it appear as a piece of marketing bla bla.

His own answers then indeed provide some valid, rather technical and low-level details -- unfortunately C++ forces us to care for these gotchas and fine points far to often. Which makes C++ unnecessarily hard to learn.

But what matters most, when it comes to judging the value of the FQA, is the fact that he repeatedly obfuscates some strengths of a more modern programming style, which is well supported by C++. Actually, I can't even help the impression that the author repeatedly nitpicks on some specific well known shortcomings, in order to derail an apprentice or student from valuing and picking up those newer practices developed after the golden age of C and assembly.

To be more specific:

  • he constantly tries to make exceptions look horrible, but in doing so tries to persuade you in a subtle way that exceptions force you to write lots of manual exception handling code "everywhere". But the key point, which really makes the difference to C-style error flags is to apply the RAII pattern consistently. And this (done with automatic variables) is a real strength of C++
  • in a similar vein, he makes smart-ptrs look complicated and superfluous, while actually their relation to RAII and the possibility of encapsulating and abstracting away tedious details should be stressed.
  • he repeatedly nitpicks on complexities of overriding non-virtual functions, and the overload resolution in general, thereby obscuring the fact, that you can use these features, together with templates, to build quite airtight abstractions with zero run-time overhead
  • he collects a whole bunch of horrible examples with code silently breaking when combining things like multiple inheritance, default arguments and casts -- thereby silently concealing that these usages are considered anti-patterns anyway. Code should e.g. be designed in a way to avoid downcasts and to prefer composition over inheritance -- and several features of C++ especially well support you in doing so or generally writing clean code
  • he again and again ridicules the access scopes, and in doing so obscures the fact that these aren't security features to hide your implementation, but are powerful features to support communicating your intention and guide the users of your APIs and library code.
  • well -- this shift away from technicalities to the soft factors, towards the meaning of the code and communication issues is one of the most notable achievements of the last two decades in our craft. In this respect it is just telling that obviously he didn't even get the point of what a design pattern is -- and repeatedly ridicules some of the most common patterns and practices.

This list could be continued... If you read the text from this view-angle, it may be indeed even an interesting read.

share|improve this answer
Yes, a "more modern programming style" would solve some of these problems, but remember that it used to be considered a feature that C code can be used almost unchanged in C++. – dan04 Mar 6 '11 at 19:18
@dan04: it still is a feature... if that's actually what you need. Being able to take some ancient library and build a modern C++ facade over it, with essentially no overhead, is fantastic (if you've ever had to work with an old Win32 API in C#, you know how quickly this devolves into madness). But just because you can use old code doesn't mean you should - or that you should let the style of the old code infect the rest of your application. – Shog9 May 22 '11 at 20:48
You had me until '...prefer composition over inheritance' - That's just another one of those knee-jerk mantras that causes misguided design decisions and needs to die a violent death. – MrFox May 13 '13 at 20:05

Well, the author has a serious tendency to rant instead of simply informing, and IMO he's approaching a lot of topics from the wrong directions, but he's basically right about most things. His discussions of the questions, once you peel away the layers of vitriol, reveal an admirably in-depth understanding of things that are going on under the hood, and do a good job of explaining why C++ is doing so many of those things wrong.

share|improve this answer
Nope; whenever I've glanced at it, the FQA shows lack of knowledge in various areas. It's as if the author just didn't bother to learn enough to address the issues he complains of, and simply decided to rant. This may not be true of all questions in there, but it was of what I looked at. – David Thornley Sep 17 '10 at 1:45

It's been years since I programmed in C++; more recently, when I tried to motivate myself to re-learning the language (and learn what has been added since I stopped using it years ago), I had a difficult time bringing myself to do it. The FQA, combined with a C++ optimisation I had to perform, helped me to understand why I have this reluctance: C++ requires me to become enmeshed in details that are irrelevant to a given problem at hand.

And I don't want to waste my time learning those tiny details.

Thus, if you should take anything from the FQA, it's this: If you are starting a new project, do not use C++. Find a cleaner, more powerful language instead.

Since I'm an eccentric mathematician, for me, that means Common Lisp and Forth; for those who wish to go the Algol route, there's alternatives like C, Go, and Java, as well as scripting languages like Python and Ruby. (Perl is decidedly not on the list, for the same reasons C++ isn't: Perl has an unnecessary, mind-numbing complexity that also gets in the way of solving your problems.)

As for the writing style, whereas some people find it unnecessarily antagonistic and confrontational, I find it entertaining to read. He also takes the time to point out where the FAQ is right, where C++'s failings are the result of human issues, and not language ones (some of the I/O stuff, if I recall correctly, is the result of incompatibility between platforms, and isn't C++'s fault), and even where the author himself is wrong.

share|improve this answer
If you're using the FQA to learn about programming C++, it's no wonder that you think you need to be enmeshed in details. If you want to learn it, find a better source for learning modern C++. If you don't, at least don't make a completely general disparaging comment. – David Thornley May 18 '12 at 22:09
I agree its an entertaining read. Just because of how silly his arguments are. – Loki Astari May 19 '12 at 14:41
I'm not using the FQA to learn about programming C++; it's merely a confirmation of why I shouldn't bother with C++. The last time I encountered it, I stumbled over a lot of little details that ought to have been handled by the compiler, but had to be specified by hand. The FQA simply confirmed to me that C++ simply has too many esoteric corner cases to get in the way of the problems that I am trying to solve, and that I'd be better off seeking solutions in other languages. – Alpheus May 21 '12 at 18:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.