C++11 FQA anyone?

isocpp.org announced "the C++ FAQ" to which reportedly Bjarne Stroustrup and Marshall Cline will link to help boost its search rank. Good stuff; also, given that the language is >30 years old – it's about time.

Which reminds me. I'm failing to keep my promise to update the C++ FQA, an overly combative reply to Marshall Cline's fairly combative FAQ, to the new standard from hell – C++11.

Could you perhaps do it instead of me? Unfortunately, explaining how terrible C++ is cannot be made into a career the way explaining how wonderful C++ is can be. So I sort of moved on to other things; I managed to summon the mental energy just that one time to write the C++ FQA, and even as I wrote it I knew that I better hurry because that energy was waning. After all, at work I managed to reduce the amount of C++ I deal with to a minimum, so there was neither a profit motive nor continuous frustration to recharge me.

Not that I haven't made money off the C++ FQA – indirectly I did make money, specifically by getting a headhunter's attention and significantly improving my employment conditions. But I don't think a new FQA's maintainer/co-author could count on something along those lines.

Still, you'd become about as widely famous in narrow circles as I am, getting maybe 200K unique visitors per year and hundreds of "thank you" emails. Most importantly, you'd do the world a great service.

There's a curious double standard in the world of programming languages. Say, PHP is widely ridiculed because, for instance, its string comparison operator converts strings to numbers if they start with "0e" and this results in unexpected behavior. And it doesn't help PHP that === works just fine.

Imagine someone mocking C++ for two char pointers comparing "wrong" with ==. Immediately they'd be told that casting to std::string (more verbose than ===) would work just fine, and that "you just don't get it".

Why is PHP – a language full of quirks which at least gives you memory and type safety – is universally ridiculed and the developers, while defending the language, never ridicule back, while C++, an absolutely insane language, is ridiculed often enough but C++ developers always counter-attack viciously? For that matter, why isn't Lisp ridiculed for EQ, EQL, EQUAL and EQUALP, if comparison operators are so funny?

The reason, IMO, is simple: PHP is not taught in academic CS courses. C++ developers are much more likely to have a CS degree, therefore both they and others treat their knowledge of crazy C++ arcana as something of intellectual value. And Lisp is the poster child of academic programming language development. Educated proponents deter attempts at ridiculing a language.

In a "rational" universe, PHP would be held in high esteem given the amount of output produced by PHP developers with little training. In our universe we have this double- or triple-standard. Pointing out the darker aspects of C++ – which are most of its aspects – thus increases the supply of a rather scarce commodity.

But why C++ and not, say, Lisp, Haskell or C#?

One reason is that C++ is arguably the craziest language in widespread use, combining the safety of C (and I can live with C just fine) with the clarity of Perl (and I can live with Perl peacefully enough). But it is of course subjective.

The thing that really sets C++ apart is its development culture and value system – a perverse amalgamation of down-to-earth shrewdness and idealistic perfectionism. The whole idea of making the best, richest, most efficient and most generic/versatile programming language of the planet – you can sense that Bjarne Stroustrup aims at nothing less – ON TOP OF C is the perfect illustration of this culture, and perhaps its origin.

Stroustrup always knew that the language would be better if it didn't have to be compatible with C and he publicly acknowledged it – the "smaller, much simpler language struggling to come out" remark. But he also knew that using an Embrace, Extend and Exterminate strategy is a much more likely way to succeed. So he did that. In fact he managed to more or less kill C or at least put it in a coma – as even C99, not to mention C11, will never be supported by the Microsoft compiler, and C89 is a really old and really restrictive standard.

A shrewd move – almost an evilly shrewd one – netting the people behind C++ fame and fortune at the expense of programmers dealing with a uniquely dangerous language full of sugar-coated death traps.

(Yes, sugar-coated death traps, you clueless cheerleaders. X& obj=a.b().c() – oops, b() is a temporary object and c() returns a reference into it! Shouldn't have assigned that to a reference. Not many chances for a compiler warning, either.)

Who did things differently? Sun and Microsoft, for example, marketing Java and C#, respectively. They made much cleaner languages from scratch, and to solve the chicken-and-egg problem – we have no legacy projects hence no programmers hence no new projects hence no programmers – they used money, large marketing budgets and large budgets for creating large standard libraries. A much more honest approach yielding much better results, I find.

And Stroustrup says about himself that he "lacks marketing clout" and says Java and C# are bad for you because they're "platforms, not languages", whatever that means.

And I'm not claiming to be able to read minds, but if I had to bet – I'd say he really believes that. He probably thinks he's your altruistic benefactor and Java and C# are evil attempts to drag you into proprietary platforms.

And you can see the same shrewdness, the same "altruism", the same attention to detail, the same tunnel vision – "this shit I'm working on is so important, it deserves all of my mental energy AND the mental energy of my users at the expense of caring about anything else" – throughout the C++ culture. From the boost libraries to "Modern C++ Design" (the author has since repented and moved to D – or did he repent?..) to the justifications for duplicate and triplicate and still incomplete language features to your local C++ expert carrying his crazy libraries and syntactic wrappers and tangling your entire code base in his net.

And this approach to life – "altruism" plus perfectionism plus cleverness plus shrewdness – extends way beyond C++ and way beyond programming. And the alternative is taming your ambitions.

This was my larger purpose in writing about all this shit. I'm pretty sure I failed in the sense that it got drowned in C++ error messages and other shits and giggles.

So maybe you'll do better than me. If you do, you might contribute to the sanity of many a young idealistic programmer – these tend to get sucked into C++'s sphere of influence, either emerging old and embittered years later or lost to sanity forever, stuck in an internally consistent but absolutely crazy way of thinking.

BTW I never wanted it to be a personal attack, in the sense that (1) I don't know what's inside the heads of people who promote C++ and (2) I can tell you with certainty that if I made something 10 times as bad as C++ and it was 0.0001x as popular as C++, I'd be immensely proud of myself and I wouldn't give a damn about what anyone thought. Just like I don't give a damn about people with so much time on their hands to actually have thousands of karma points at StackOverflow explaining just how lame C++ FQA is.

In this sense, C++ is fine and a worthy achievement of a lifetime. Especially in a world where Putin is a candidate for a Nobel Peace prize and Obama already got one.

I basically just think that (1) C++'s horrible quirks are worth pointing out and (2) there's something to be learned from this story about the way we pave the road to hell with our good intentions. That's all.


A lot of people have spoken about "a C++ renaissance" when C++11 was ratified. I tend to agree – indeed the new standard is a fresh doze of the same thing that C++ always was: "zero-overhead" pretty-looking syntax with semantics quite horrendous once you think what it actually means.

Fittingly for a new revision of the C++ standard, more things we could once safely count on have gone with the wind. For instance, anything you could pass to a function used to be an expression, and expressions had one and only one type. How ironic that this revision, the revision that finally capitalized on this fact by introducing auto, also made this fact no longer true: {0} could be an int or an std::initializer_list, depending on the context. Context-dependent types were one thing that Perl had (scalar/vector context) but C++ didn't have.

(I have observed someone do this: _myarr[5]={0}; – they had in the .h file the definition int _myarr[5] and they remembered that this thing could be initialized with {0} in other contexts. What they did wouldn't compile in C++98; in C++11 it promptly assigned the int 0 to the non-existent 5th element of _myarr, and the usual hilarity ensued. Imagine how PHP would be ridiculed for this kind of little behavior – and PHP at least would never overwrite an unrelated variable with garbage. Imagine how with C++, the poor programmer will be ridiculed instead.)

This is nothing, BTW – it's not the kind of thing the FQA would normally poke fun at. We have bigger fish to fry. For instance, C++11's "closures" or "lambdas" – the preposterous thing where you say [](){…} and an anonymous struct gets generated. BTW it's one of the reasons I urged everyone where I work to upgrade to C++11; because it lets you implement a nicely-looking parallel_for. In C I would have added a compiler extension for it AGES AGO but extending the C++ grammar? No sir. I waited patiently until C++11 lambdas.

So, C++11 lambdas. Someone needs to write everything about those hideous capture lists – are references captured by value or by reference?! – and how you can end up passing dangling references if this closure thingie outlives variables it references (we don't need no stinking garbage collection! but why doesn't C++11 let one capture variables by std::shared_ptr?.. It's so much better than gc!), and about the type of this shit and how it looks in debuggers, and about std::function etc. etc.

And this won't be me because frankly, I don't have time to even fully master this arcana anymore.

If you dislike C++ and have the time to write about it, I'll gladly pass the torch on to you; specifically I'll redirect C++ FQA to point to your site, following the example of Bjarne Stroustrup and Marshall Cline. Or we could run a wiki, or something. Email or comment if you're interested.


#1 Alex on 03.22.14 at 4:04 pm

I'd love to if I had the time to gain enough depth of knowledge of C++11. But for my professional use of it I try to learn things that work and are safe and automatically being suspicious of the complex and clever.

I've always loved C++ whilst always too thinking it really should never be used for real.

#2 Tom on 03.23.14 at 3:12 am

You know something is wrong when most people are using a tool that is too complex!

#3 Tom on 03.23.14 at 12:36 pm

Yeah, like most people use a computer. Must be something wrong then.

#4 Mate on 03.24.14 at 4:04 am

"PHP [..] a language full of quirks which at least gives you memory and type safety". Except, if you look at the code of PHP you'll know it's *really* not safe. There are so many people sitting on so many PHP zero-days, it would be hard to count. You just have to run it with valgrind/llvm-sanitizer and be amazed. It would be hilarious if it wasn't used by millions, openly exposed to the web.

#5 Yossi Kreinin on 03.24.14 at 1:27 pm

Perhaps you're right; if so I'd guess that say Facebook's PHP implementation is safer. The thing is, PHP the language – which in the long run matters more than the current version of php the standard implementation – makes a safe implementation possible. A memory-safe C++ implementation is only possible in a completely impractical sense – namely if pointers aren't implemented as machine addresses. Of many, many C++ implementations not one ever attempted this over the past decades and for very good reasons.

So you'll keep getting those zero-days forever if people program stuff in C++ that is exposed to attackers. Fortunately, programming in C++ is otherwise so cumbersome and unproductive that few people do such things.

#6 Stefan on 03.25.14 at 1:54 am

I really feel sorry reading so many defamations towards the C++ language.
Maybe C++ is a little complex, but is is the only native language out there which is suitable for large projects.
It is no problem to write a image recognition software library in C, or other system-software, but it is IMPOSSIBLE to write large applications in C.
Large applications consist of OBJECTS and C++ provides support for OO. OO modelling of software is way more easy to do than forcing a world of objects into a structured approach.
Maybe in the future D has the chance to replace C++, this too depends on the mayor compiler-vendors.
I really wish the author would take himself the time and LEARN the language and he would not only blame about the fact that he can't read it.
My dear author: Have patience, learn it, use it and LOVE it ;) instead of wasting your energy on hating the unknown.

#7 Xirdus on 03.25.14 at 3:53 am

@Stefan: I think Linus Torvalds would like to have a word with you ;)

#8 Suisei on 03.25.14 at 4:16 am


If Linus Torvalds wants to have a word with someone, are you his secretary who can arrange a meeting? Will he explain why the C developers working on Linux continue to introduce security bugs in every single release? (An undeniable fact, BTW)

#9 Yossi Kreinin on 03.25.14 at 4:44 am

@Stefan: erm… at what point is someone entitled to claim that he "knows" this shit (which I don't exactly claim but let's say I'm far from a beginner and I would for instance very much doubt that you can read C++ better than me)?

#10 Michael Moser on 03.25.14 at 5:59 am

Thanks for the article

> they used money, large marketing budgets and large budgets for creating large standard libraries. A much more honest approach yielding much better results, I find.

C# and Java are not supposed to be portable to whatever platform there is; they compile to one bytecode format that runs on one virtual machine;
here you have much more assumption of where the shit runs on. Right from the start you have to define a memory model that works with threads, not as an afterthought in version 11.

By not having to be cross platform you can have higher level and more specialized libraries – like thread pools; GUI toolkits or cryptographic libraries. I think that's what he means by 'platforms, not languages';

In C++ they took the 'lowest common denominator' approach, whatever that means.

Also Java and C# had the luxury to avoid some of the mistakes of C++, like multiple inheritance.

#11 Michael Moser on 03.25.14 at 6:03 am

Also are you sure that C has been extinguished?

gcc does c99 and is working on full support of c11; I would dare to say that GCC is bigger than Visual C in this day and age (at least i would not know how to use the bloated development environment of Visual C, even if forced at gunpoint)

#12 Michael Moser on 03.25.14 at 6:32 am

Yet another point: Dangling pointers to stack locations is something that can be done in C, this effect can be achieved without much effort.

Of course C does not have this awful amount of stuff going on implicitly behind the scene and it does not have template headache; however in C you can make a awful mess with long wound precompiler macros (just ask the Linux kernel)

You are right that it C is much more straightforward.
However at this point in time i welcome C++ if the customer pays for it; though you are right that i probably could have done better with the effort that it took to learn it…(sigh).

#13 Michael Moser on 03.25.14 at 6:37 am

Preprocessor macros, not precompiler macro's. And GCC has its own extensions that are not portable to anywhere else. Well at least they took over variadic macros in C99.

#14 Yossi Kreinin on 03.25.14 at 6:37 am

Java and C# could have been native languages (as in gcj or say similarly to D or go which are gc'd but native) and they'd be better in C++ in all the same ways. Also JVM and .NET run on many platforms and it makes very little sense to call C++ not-a-platform but these two things a platform.

Regarding C: a lot of projects want to be portable to VS and hence avoid anything above C89. Not that C was "extinguished" of course, but C++ is very widespread in places where C could be a much better fit.

#15 Tomasz on 03.25.14 at 10:38 pm

In Polish, we have a saying more or less "there's no point in kicking eachother with a horse". C++ is this kind of massive beast, but it is here to stay, together with its mass of fanboys, but also some smart "consultants" (language lawyers).

It is also true what they say – that C++ is "a federation of languages". It really covers a large subset of C, which leaves us the option to stick to "predictable" constructs. There's even std::malloc, std::realloc and std::free – if you don't listen to C++ fanboys and televangelists.

Then there's the "older version of Java" – class hierarchies and polymorphism. You know, all this "a class that has any virtual methods, needs a virtual destructor" stuff. It's mostly pathetic.

Thirdly, templates. This shouldn't be easily dismissed – the Lisp guys can now, in C++11, have all their fun from the good ol years, with variadic templates.
The problem is when you have to port some code from MSVC to G++ and there are unqualified references to dependent types and names.

Right now, because of template abuse, they came up with constexpr. Of that I know little about, but it seems like an acceptable variation on macros and constant folding.

What C++ is unsuitable for, among many many other things, is being an intermediate language (unless it will be in fact C). My colleague has written a C++ code generator for our software, and it was and still is a ton of pain, even for a genius with aspergers like him. We also have another tool, which takes C++ as input (or pretends to), and this is actually impossible without being a full blown compiler frontend (which our tool isn't). One tiny example to show why:

template void f();

const int x = 1;

template <int, x void f() { /* some code to further process */ }


In the end, I try to worry about what C++ does to me. I use it, and it offers me some possibilities and some pain.

(Digression: C++11 is arguably some improvement over C++03… unless you still need to support older compilers and cannot use the plethora of new features, or have to #ifdef them out. Not too much old code goes broken. With Python 3 – this is not the case. And is is being shoveled down the throats of innocent newbies.)

I certainly wish, that there will be either someone, or a collective effort to hoist the FQA standard high, and keep it a source of up-to-date C++ information. Free from dogmas etc.

#16 Tomasz on 03.25.14 at 10:50 pm

The HTML sanitization ate my example. Replace square brackets with agle brackets:

template [typename T, bool b] void f();

const int x = 1;

template [int, x [ 5] f() { /* … */ }

// x < 5 – this is the unbalanced "less than sign".

It comes from C++ philosophy of "keyword? no, let's add a new meaning for an old token." like && for (usually) r-value reference. Unless its in a function or method template after the bare template argument (like T&& – then it can also be a "normal" (l-value) reference. But all readers know this already, right?

#17 Yossi Kreinin on 03.25.14 at 10:59 pm

C++11 is indeed a better thing to upgrade to than Python 3… Sigh.

As to C++ – in Russian we have a saying "nothing is eternal under the moon"…

#18 Tomasz on 03.25.14 at 11:00 pm

I posted an explanation, but forgot to assert that I'm a human. My example got tampered through some HTML sanitization. Imagine square brackets as angle ones:

template [typename T, bool b] void f();

const int x = 1;

template [] void f[int, x [ 5] () { /* … */ }
// unbalanced [

#19 J on 03.26.14 at 4:52 am

I have spent most of my career (short as it has been so far) working with C++, and the FQA was absolutely invaluable to me. Not only for pointing out C++'s (many) potholes to swerve around, but also as a reassurance that no, it's not just me, the language really is that bad. So, thank you, very much, for creating this resource. I can't say I agree with everything in there (e.g. I feel that C++ exceptions, while clearly the worst implementation of the exception feature in any language that I've seen, are slightly better than useless) but seeing a critique of C++ from someone that has had to get deep into the darker corners of the language has resonated with me.

C++ is a language that looks fantastic at first glance, and the deep, fundamental problems don't rear their head until you're working in the "second 90%" of the development effort in a large, multi-developer, multi-hundred-thousand-line project. This is why I now have a deep-seated distrust of developers who really, genuinely like C++. I frequently find that they're the sort of developers who switch projects before the later integration stages, while I generally find myself in the position of desperately trying to clean up the mess. At a glance, Stefan up there fits that description. The tragic part is that he's right that C++ is frequently the only reasonable option for a development project, simply because there's nothing else really available. C++11 (which I've been using here for a couple of years) grinds smooth some of the rougher edges in the language and the standard library (hey, you can finally create a std::fstream using a filename from a std::string, whoopee!) but the deep, underlying problems remain; I never really expected anything different.

#20 Yossi Kreinin on 03.26.14 at 5:31 am

Thanks for your message!

I think the two big things that machines can do to fight C++ is (1) distributed build coupled with incremental linking to make rebuilds tolerable and (2) dynamic instrumentation tools along the lines of Valgrind checking for various errors (unfortunately we're very, very far from a comprehensive dynamic error detection tool for C++). Without these things large projects become incredibly costly to maintain with 50% or even 90% of the time spent fighting the bloody language.

Unfortunately, on top of that, little can be done to make C++ readable except maybe for draconian coding guidelines – something I for one am not very good at.

#21 Richard on 03.26.14 at 5:02 pm

The second Lisp predicate is EQL not EQU and there was a C(indeed not C++) compiler where pointers were not machine addresses: ZetaC which ran on the Symbolics Lisp machines.

#22 Yossi Kreinin on 03.26.14 at 10:58 pm

Thanks for the correction, and as to LispM – let's call it the exception that proves the point (specifically it proved this point by going extinct).

#23 Michael Moser on 03.27.14 at 1:28 am

>Java and C# could have been native languages (as in gcj or say similarly to D or go which are gc'd but native) and they'd be better in C++ in all the same ways

That's because of the preprocessor; with C it gathers one source file with all included headers into one text, compiles it and type checks everything against the intermediate representation;

Java and friends compile one file as is and do type checking of what is known locally in that file, if there is a call to a method of an object that is not known from given information then that call is not type checked at this stage;
Once all other files of a package have been compiled then it can perform type checking of calls from objects declared in the same package; the object signature lookup is conveniently done from class file – the same format that is used to run the stuff (but you can do without that like in D)

So that's another major point where backward compatibility with C is not quite helpful.

#24 Michael Moser on 03.27.14 at 1:30 am

posted too quickly: meant to say that many inconveniences of C++ syntax come from the way it uses the preprocessor.

#25 Nayuki on 03.28.14 at 9:52 pm

> Java and friends compile one file as is and do type checking of what is known locally in that file … if there is a call to a method of an object that is not known

Have you used javac before? When compiling a .java file, the compiler examines every class that is being referenced. If a class has no .class file or its .java file has a later timestamp than its .class file, then that .java file is compiled as well – recursively.

(Btw because of this behavior, javac fits Make's one-file-at-a-time-compilation model very poorly.)

#26 Apprentice on 04.05.14 at 6:53 pm

you are a hero :)

#27 Pete on 04.10.14 at 6:08 am

Yossi, remember the saying "if you want something done right, do it yourself."

It's up to you to update the FQA. (Cline's FAQ hasn't changed that much anyway.)

What else can I say? Your FQA is a great resource. I have it bookmarked and downloaded. I even used to link to it for fun and giggles when helping beginners on the cplusplus.com forums.

I don't do that very much nowadays, because I want to get along with the other members… some of whom openly object to your stated goal of convincing readers that "C++ shouldn't be used" and call your FQA a troll site. After all, it's not my business to defend your FQA.

Anyway, I think your FQA is valuable. It is very organic and warm, and the "oh so it's MY fault" when talking about self-assignment is just one example of that.

#28 Yossi Kreinin on 04.10.14 at 10:47 am

Well… thanks, I guess. "Warm"… I'm sometimes afraid "hot", or hotheaded… Maybe if I toned it down people wouldn't think of it as a troll site.

#29 Jeff on 04.10.14 at 11:02 am

I'm pretty sure in some talk not too long ago Herb Sutter said that they were aiming, finally, for C99 support in Visual C xx. I thought the talk was more recent than July 2013, but that's where searches come up with support for this notion.

#30 BN on 05.09.14 at 9:30 pm

From what I gather, the difference is that C++ is "insane" for a reason (performance/etc) and people who use it generally know this or they would use something else, while php is bad for no particular reason.

#31 Yossi Kreinin on 05.10.14 at 4:34 am

How does C++'s undecidable grammar help with performance, exactly, to take one example of very, very many? The real difference is C++ has all those apologists with Stockholm syndrome while PHP doesn't; also C++'s creator thinks his creation is perfect and wins people over by explaining his rationale at length, making them feel like a language designer through identification with the narrator, while PHP's creator calls himself a "bad programmer" (and Ritchie called C "quirky and flawed", etc.) – note that in reality it's a big question which of the two is the better language implementer.

#32 lmm on 05.12.14 at 2:43 am

Maybe C++ doesn't have to be that way, but there's (as yet) no alternative that absolutely proves it – I mean, most of us have moved on to Java or C# or beyond, but the C++ advocate can still make the case that it's higher-performance (or that you can write libraries that can be called from other languages).

By contrast with PHP we just look at Python or Ruby and see that it could have been better in every way. (I guess you could argue for PHP's faster deployment, but if you're that kind of crazy then mod_python does exist, so it's possible in other languages)

#33 Yossi Kreinin on 05.12.14 at 2:55 am

Well, C is better than C++ for high-performance code so there's your proof… If you want C++ craziness – many people have grown to think of its problems as requirements – then indeed nothing is better than C++. But that is just as true for PHP (as in, only PHP has <?php…)

#34 Pete on 05.18.14 at 12:04 am

How do you argue that "C is better than C++ for high-performance code"?

I can think of two things: the executable file is usually bloated; and there's the overhead of hidden function calls (constructors, destructors, overloaded operators).

Is there anything else you have in mind, Yossi?

#35 Yossi Kreinin on 05.18.14 at 2:23 am

With C you know what's going on (it's not just a question of hidden functions but also say overload resolution/template specialization/binding in general), it compiles faster, etc. See http://yosefk.com/c++fqa/defective.html

#36 HOKUS POKUS on 06.29.14 at 3:37 pm

PHP is ridiculed because its flaws are unacceptable. As a language mainly developed in the late 1990s and early 2000s, it should not have most of the serious flaws that it does have. They are unjustifiable given the state of knowledge when it was developed.

C and C++, on the other hand, pre-date PHP by decades. They were pioneers in the field. In such a situation, mistakes are expected to be made, as nobody had experience about what to avoid.

On top of that, we've seen efforts from the C++ community to help avoid some of the problems that affect it. The faulty aspects may still be around and supported in order to retain compatibility, but there is often new functionality that presents compelling and usable alternatives to faulty functionality. But when it comes to PHP, we've seen very little done to try to address the problems that it suffers from.

C and C++ have flaws because they pushed at the boundaries of knowledge, yet at least some effort has been made to mitigate these. PHP has inexcusable flaws that never should have happened in the first place, and aren't being fixed today.

#37 Yossi Kreinin on 06.29.14 at 5:21 pm


C++'s grammar is a perfect example of something that was known to be a bad idea when Stroustrup got his CS PhD and yet it's there. PHP is somehow a tad easier to parse.

"Compelling and usable alternatives"? As in cout vs printf, or STL algorithms vs loops? Right.

Where "C++ pushed the boundaries of knowledge" I can't even imagine; most of it was (badly) copied from other languages. Maybe const represents C++'s contribution to computer science… it's a good thing nobody was crazy enough to copy it to another language.

And it's not like PHP doesn't have new releases or new "best practice" advice. In fact I doubt it's worse than the C++ advice where every decade they tell you to use a new idiom for everything (remember auto_ptr?)

The only difference between PHP and C++ is the existence of cheerleaders thinking this shit pushes the boundaries of anything.

#38 Andrea on 07.09.14 at 11:38 pm

Your FQA was enlighting for a undergrad like me. It explained a lot of things and pushed me to experiment with Ada and understand how languages work, or are supposed to work

Recently I witnessed another "failure" of C++-related software. People kept talking about the Eigen matrix library as it was the latest panacea. It turns out that, predictably, the objects created with that library do not correctly handle a low-level issue like alignment, which is best handled by the compiler, and so code using Eigen may or may not segfault, in different ways. Cool, isn't it?

I'm not interested in C++ at all. In my sector, mathematical programming software, all I see are simple libraries with ugly interfaces and lots of unintelligible boilerplate. So much for the language everyone uses. People who seek alternatives either translate the library in python, gainging little over expressiveness, or implement their own little scripting language, which can become a nightmare to work with. C/C++ have been a real drag for our field.

Anyway, coming back in topic, I read briefly about rvalue references (people never wonder whether having obscure names and complicated concepts hinders solving complicated problems rather than helps it). It turns out, again, predictably, that the newest addition fucks up template instantiation, type conversion and the like, but can also force to duplicate code to cater to the new type specifier, as with other C++ constructs.

#39 Yossi Kreinin on 07.11.14 at 10:56 am

Eigen… thanks for the tip, will try to stay away from it.

As to rvalue references – indeed it's quite the can of worms, one of those things in C++11 that I wonder if I'm even going to invest my time into figuring out.

#40 1011011 on 07.18.14 at 1:21 am

C++ is and always has been a pointer hell just add subtract and bash your face in for clean stable code.

#41 Justin L. on 08.27.14 at 9:11 pm

Nit: s/doze/dose.

In all seriousness, I don't think too many people are capable of writing outrageous, funny-cuz-its-true commentary comparable to your FQA (or even this blog post). Good luck finding a worthy replacement!

#42 David M. on 08.27.14 at 9:45 pm

The FQA is one of the most accurate and useful descriptions of C++ that has ever been written, and was obviously written by someone, Yossi, who knows far more about C++ than the vast majority of C++ programmers. Those claiming otherwise advertise their profound ignorance.

#43 Keith Thompson on 08.27.14 at 11:08 pm


I suggest that's not a good example. It clearly (at least to me) is meant to be an assignment whose LHS is element 5 of _myarr. If the {0} were an initializer, the LHS would have to be a *declaration*, not just an expression; it would have to define the element type of the array. The author of that line of code just made a mistake; I don't think that particular mistake illustrates a weakness in C++.

Someone who thought an array object could be assigned like that would probably try to write:

_myarr = {0};

and then realize, when the compiler rejects it, that the initialization needs to be on the definition of the variable.

#44 John S. on 08.28.14 at 1:13 am

Keith Thompson,

All that arcana, simply to declare an effing array?! No other language even comes close to the stupidity that is C++.

#45 Keith Thompson on 08.28.14 at 2:22 am

John S. : I'm not sure what "arcana" you're talking about.

To declare an array:

int myarr[5];

To declare an array and initialize all its elements to zero:

int myarr[5] = { 0 };

To assign a value to an element of an array:

myarr[2] = 42;

There are admittedly some oddities in the treatment of arrays (which C++ inherits from C). The fact that { 0 } can be used as an initializer but not as an expression is inconvenient. But just declaring the array is straightforward.

#46 Holden McGroin on 08.28.14 at 5:45 am

C++ rules. PHP blows chunks

#47 Ian on 08.28.14 at 11:31 am

I can't count the number of times I've asked a question on S.O. on a complex C language issue, and received as an answer "you should move to C++ (you dinosaur)", typically from a programming student with approximately zero experience in field code deployment and maintenance.

It looks to me that programming schools are the main driver that push C++ on the agenda, since it has become the academic reference, on the ground that it is "object oriented", so it must be a great thing.


I also deeply regret that C had to suffer from the very existence of C++, which implicitly pretends to be "C next gen", thus killing any evolution of C stand alone. C99 is great, but it would deserve more care to evolve with our time.

#48 Fernando on 08.28.14 at 9:05 pm

C++ is a tool. If it is too complex for your, don't use it.
You could use another language like Java, Python or Javascript and let your CPU melts.

#49 Dani on 09.02.14 at 7:32 pm

And if English grammar is too complex for you, don't use it :)

#50 Redbrain on 09.13.14 at 4:52 am

Thing is system level development is almost dead. Game dev, kernels and maybe compilers depends are about the only reason to look at c/c++. I love c I hack on gcc and commit to it. But the problem is most work people do these days are web apps or app development so really there isn't a need for the speed increase they provide abd higher level applications are faster abd easier to develop in python or java etc. you not going to start writing JavaScript front ends to c++ back ends outside of legacy code projects. The language more over gets abused terribly in real life mixing c types and idioms into c++ they are two very different languages but it really does get very very ugly abd hard to read fast. Although it's much easier to develop mocking unit tests in c++ than pure c so a lot of the reason to use c now gets harder if you like test driven development.

Tldr: c++ is abused very easily, readability sucks more features aren't really solving any real problems. Not enough reasons to use c++ in app development or web stacks.

#51 BaCaRoZzo on 09.18.14 at 10:24 am

Thanks again for the effort put in your FQA. Even if you writing style can hurt someone's feelings I've always found your ARGUMENTS rock solid. :) I think it's a pity that C++ community does not accept criticisms. After all (constructive) criticisms (like yours) are the best way to improve and get better.

For what concerns Stroustrup, I'm not sure that he sees Java/C# as the ultimate evil.
Citing him from an interview for the 5 most important languages you need to know, he says "[...] C++, of course; Java; maybe Python for mainline work… And if you know those, you can't help know sort of a little bit about Ruby and JavaScript, you can't help knowing C because that's what fills out the domain and of course C-Sharp. [...]".
So, at least, he recognizes the importance of such languages nowadays. Not a statement of love at all, anyway.

#52 Tomalak Geret'kal on 09.26.14 at 7:42 pm

Your C++ vs PHP comparison is broken. C++'s ridiculous oddities stem from _consistency_ and robustness of specification. It may have resulted in a silly language that's insane to write in, but at least it does all make logical sense (if only from an academic point of view). PHP's ridiculous oddities are the actual opposite: inconsistencies meted out in the design for no particular reason.

#53 Yossi Kreinin on 09.26.14 at 10:14 pm

This wouldn't be relevant even if it weren't patently false, which it is. Example: C++'s undecidable grammar – a problem PHP doesn't have – does not follow from any requirement, reasonable or bogus, ever invented by Stroustrup or any of the many C++ apologists. It's just a goofy mistake by a CS PhD who should have known better. From an "academic" point of view this one appears particularly brain-damaged.

You're not the first commenter whom I give this reply, because you're not the first commenter saying more or less what you said… Why do I even bother? (And this is why attrition precludes my effective functioning as the FQA maintainer.)

#54 Yossi Kreinin on 09.26.14 at 10:15 pm

…See specifically comments #30 and #31.

#55 nice byte on 01.04.15 at 6:10 am

Just wanted to point out that your example with string comparison is wrong – in C++ "char*" is not a string, it's a *pointer* and comparing pointers themselves (not the data that they point to) actually makes sense, while PHP's behavior in that example is completely unjustifiable.

#56 Yossi Kreinin on 01.04.15 at 8:28 am

You illustrate my point wonderfully. Why isn't PHP's behavior justifiable, exactly? Many, many languages have many different comparison operators and some of these do type conversions. (In fact, nothing prevents you from defining an operator== comparing std::string and int, PHPifying C++ to some extent.)

As to "what char* is" – well, "abc" definitely looks like a string but is a char*, not an std::string or any reasonable string type, and comparing its address with anything is never actually useful, once you think about it. It's definitely way less useful than having "5"==5 evaluate to true. And while there are historical and other reasons for it all, the extent to which you perceive this as "justifiable" is exactly the extent to which you've learned to love C++'s shit instead of seeing it for what it is…

#57 red75prim on 06.21.15 at 12:53 am

I'd like to point out that now there's alternative to C++. Rust.

#58 Yossi Kreinin on 06.21.15 at 8:40 am

First of all there were always alternatives to C++, just not with the same feature set as Rust… As to Rust – I have to look into it… It looks very promising, but also very hairy and without first-hand experience it's hard for me to tell how it is to program in it. I guess it's "the only alternative to C++" if you want something high-level without a gc. There's a reason why most languages have gc, though, and Rust's complexity in the memory management department basically puts a spotlight on that reason… Still, you need gc-freedom when you need it, and I hope Rust proves to be what it promises to be.

#59 Lukas on 03.24.16 at 4:27 pm

I like C++ a lot for some reason. Despite this, I consider the C++ FQA a really nice resource, and the provocative tone makes for a more entertaining read, and is refreshing in the face of the hype. As far as I recall, it also is factually correct, so my like and your dislike comes down to how much the problems objectively disgust us.

I can definitely see how the paternal tone in the old C++ FAQ reads very provocatively to someone critical of C++.

As for C++11 onwards, I think the additions are really nice (even though they're burdened by the typical C++ quirks forced by a desire for compatibility). I think they make programming in C++ much more productive and when used at the exclusion of some older styles at least a bit safer.

Of course, the old things don't really go away, so this takes some studying. I already knew C++ pretty well, so these were "just" additions to me (admittedly, some still difficult to grasp). Looking back, considering the amount of time I've spent, the prospect of learning C++ from scratch seems daunting. I don't think I would spend this much time on a new language today.

#60 Lukas on 03.24.16 at 4:28 pm

* I meant subjective disgust.

#61 Yossi Kreinin on 03.25.16 at 10:09 am

Thanks a lot for your feedback!

#62 Alek on 11.07.16 at 6:30 pm

"In this sense, C++ is fine and a worthy achievement of a lifetime. Especially in a world where Putin is a candidate for a Nobel Peace prize and Obama already got one."

This quote just epitomizes the very era we currently live in. Way to go, Yossi.

It is sad, however understandable, to see the FQA come to a halt, at least for a time. Specially now that, in the eve of a new "C++ Standard ™", and after a number of "committee meetings" and several issued "proposals" (hahhaha!), we're provided with this fresh, truly rich material for even more intense reveling at the laughing insanity that C++ and its community is.


#63 Yossi Kreinin on 11.07.16 at 7:01 pm

Well, it's on GitHub (https://github.com/yosefk/cpp-fqa) so anyone can edit/update it. Unfortunately, to date, the only change request I got was replacing "retarded" with "silly", the commit message being "removing ableist language."

#64 Borsch on 01.12.17 at 9:49 pm

> Well, it's on GitHub
> the only change request I got was replacing "retarded" with "silly", the commit message being "removing ableist language."

Ironically, accepting this might actually let the project be on Github for a longer time.

Github went full-SJW lately, actively censoring repositories even for stuff like this. (one of the examples: https://www.reddit.com/r/KotakuInAction/comments/3eizt4/socjus_github_bans_a_popular_webm_conversion/)

If you think this might be an issue, consider hosting it on https://gitgud.io or https://gitlab.com

#65 Yossi Kreinin on 01.12.17 at 10:09 pm

I dunno, I don't particularly give a shit one way or the other. If they kick me out, I'll go elsewhere. I just put it where I thought the most users are.

Leave a Comment