C++ Frequently Questioned Answers

Yossi Kreinin has recently posted his C++ FQA which he announced on news:comp.lang.c++.moderated.

I can understand Yossi's frustrations with C++. It is an extremely complex language with a number of difficult to grasp arcane rules. It is also a very expressive language which can create very efficient applications in the right hands. Yossi has also clearly spent a lot of time on his Frequently Questioned Answers, but at heart I think he knows he's trolling.

The following post was rejected from comp.lang.c++moderated, entirely properly I think. Just to be clear on this point, the moderators did their job properly in rejecting the post. I think it is Yossi who is hiding behind them because he's afraid to actually stand up and defend himself on his own in a public forum.

On Oct 26, 3:27 pm, Yossi Kreinin <yossi.krei…@gmail.com> wrote:

The C++ FQA Lite is available here:http://yosefk.com/c++fqa It's based on the comp.lang.c++ FAQ -http://parashift.com/c++-faq-lite

While certainly not off-topic for comp.lang.c++[.moderated], the FQA can make a flame bait. Apparently, a good way to prevent flame wars is to have the discussion in a moderated newsgroup (I have a recent experience with a weakly moderated forum, and it was suboptimal). You can also e-mail me privately (if you're human, you'll find the address at the site). One thing I'm definitely interested in is whether I got any facts wrong, and if I did, which ones.

Much of it reads like the rantings of somebody who is finding learning the language and its idioms hard. I have many of the same feelings about monads in Haskell, but the solution is for me to spend more time in learning them, not to spend my time in writing rants about them.

Much of the advice is dubious at best and probably wrong for most users of the language. For example 10.3 suggests that using constructors is bad. What would a better alternative be? Two phase initialisation makes your job as a class maintainer easier, but shifts the burden to every use of the class.

The problem with the sort of advice you give is that it pretends that all use cases are the same. They aren't. If the constructors are too hard to write for a class it generally points to bad class design, not poor language design. If you find that you want to repeat snippets of code across constructors then you probably have several members that should be in their own sub-object with a suitable class that abstracts out the details. If you need to pre-process the arguments before they are usable you probably want a meta-class method to act like a factory (maybe a static function in C++ or a free standing function, or if the needs are very complex then a separate factory object).

These are all design issues, and although you are right that the language makes some designs easier than others, it is not right that a poor design choice can be blamed on the language.

I could go on about the terrible advice in things like 10.6, but I won't right now.

Some of the language criticisms are I think spot on though. 10.11 and 10.12 as two examples. I suppose that 10.11 is probably solvable given modern C++ compilers as a starting point, but I don't see how 10.12 can be done without a lot of extra rules.

The problem with your description of 10.12 is that you gloss over why people want to initialise objects before main is entered. Nearly every C library forces you to call an initialisation function within main, but in C++ that initialisation can be done automatically by the library. Again, it's a little harder for the library writer (but not much), but a lot easier for the library user - this seems like a reasonable trade-off to me. Do you really think that calling all of that initialisation code in main in a C program is faster than running it automatically before main in C++?

K