What is your opinion of C++ Frequently Questioned Answers?

Question

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

Answer 1

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++.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

1. The best answer I ever found about the merits of the FQA is at stackoverflow here: http://stackoverflow.com/questions/3171647/errors-in-c-fqa . See the Answer from Mike Seymour.
2. I think it is far more useful to look at the summary of the FQA "Defective C++" here: http://yosefk.com/c++fqa/defective.html than looking at the full FQA.
3. To avoid a flame war, I will not comment what I personally think about the FQA.

Answer 7

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.