Slashdot Mirror

yosefk writes:

If we use exceptions, we have to write exception-safe code - code which frees all resources when the control is transferred from the point of failure (throw) to the point where explicit error handling is done (catch). [...] To solve this, you are supposed to use RAII, meaning that all pointers have to be "smart"

I think this was written before C++11 standardized two suitable smart pointers in std::unique_ptr and std::shared_ptr. Stash resources allocated by the constructor in a smart pointer.

In 17.4, yosefk continues:

How are you going to figure out whether your program manages resources correctly or not when it's littered with smart pointers of different kinds, especially in [...] cases when "ownership" (the right & duty to dispose a resource) is passed from object to object

The replacement of the problematic std::auto_ptr with std::unique_ptr that uses C++11's new move-construction semantics and addition of std::shared_ptr solved, as yosefk mentioned with the references to Boost pointer templates that made it into TR1.

I wonder whether yosefk plans to refactor this page into "Defective Modern C++" to parallel the title of a 2014 book by Scott Meyers (ISBN 9781491903995).

Congratulations: You just created a time of check to time of use (TOCTTOU) race bug. Consider what happens if another process deletes the file between the call to isfile and the call to open.

Then open() throws an exception and you're no worse off than if you had blindly called it, "expecting" the exception, in the first place. My examples were minimal in order to show the overall pattern of execution; I never claimed they were complete or that they included all the error handling they should actually have.

exceptions should be used much more sparingly in C++ than in Python because they don't work as well in the former.

Could you explain what you mean by this? Is it that Python tends to throw (predictable) exceptions in cases where C++ has (unpredictable) undefined behavior?

http://yosefk.com/c++fqa/defec...

Uncertainty goes both ways. I never thought of it this way until reading this interesting blog post. Companies don't know how good the worker really is, either.

You'll get a lot of insights on C++ after doing do.

- http://yosefk.com/c++fqa/

- http://stackoverflow.com/quest...

- https://gist.github.com/klmr/5...

- http://c2.com/cgi/wiki?CppBash...

You are what is called a "C++ apologist". You are comparing C++ to nothing except itself and abstract complexity (and offhandedly VisualBasic), instead of actually coming to terms with the real problems of C++.

Let me offer you a few pieces of evidence of C++'s failures.
* C++ has a text preprocessor. A solution to engineering constraints of fucking 1970. No one has or will ever do that since 1975. Everything is and should be resolved symbolically.
* C++ is meant to be able to compile C code with no to minimal changes. This really makes
* D. Read http://dlang.org/cpptod.html which is a description of how another systems-level language dealt with perceived drawbacks of C++. I don't think D is perfect by any means, but there are many thoughtful improvements to C++.
* Read http://yosefk.com/c++fqa/defec... for a bunch of valid complaints about C++ (granted, many of those can be argued).

he clearly doesn't understand C++ and has some very odd ideas about it

Maybe, yes. (I'm quite pro-C++ myself, at least compared to C; I clearly think nothing like Torvalds.)

I don't see how having constructors instead of manually calling macros and virtual functions built into the language (much better dcache performance than the C version) would do anything but be an improvement.

How would the cache performance be different? Also, there are things not to like about C++ constructors, error-handling being one of them.

Agree that any sane developer wanting to write a new C++ compiler (backend) or static-analysis tool would almost certainly be unwise to do anything but use an existing frontend (Clang, EDG... g++ maybe, I guess).

The general consensus as I understand it is that the <iostream> wing of the C++ standard library is hairy, convoluted, time inefficient, and space inefficient in implementation. What's the better solution? <cstdio>? Is Boost.Format, as shutdown -p now suggested, any good?

Initial reaction: they've reinvented VMware player (an easy to use x86 virtualization tool)
Subsequent reaction: this is more about making syntax extensions to the core language, easy to do. And still preserving static typing.
So in short . . . anyone who understands it could trivially write extremely obfuscated programs that still run correctly. Primary competitor: C++

http://yosefk.com/c++fqa/

I agree, and will raise you this.

If you're doing C++ everything by Meyers.

If you are doing C++, you absolutely must read the Frequently Questioned Answers:

"C++ is a general-purpose programming language, not necessarily suitable for your special purpose."

It's a little (though not much) out of date, as it does not cover C++11. But the author has some comments on it, too.

Obviously I am going to be modded down, but hey. Truth is truth.

If you're doing C++ everything by Meyers.

If you are doing C++, you absolutely must read the Frequently Questioned Answers:

"C++ is a general-purpose programming language, not necessarily suitable for your special purpose."

It's a little (though not much) out of date, as it does not cover C++11. But the author has some comments on it, too.

Obviously I am going to be modded down, but hey. Truth is truth.

When I'm working on any project of significance (which isn't often anymore), I tend to write in C, so what you said is about as far off-base as you can get.

I don't know why you're fanboying about a language like C++ (or any language, for that matter; being a fanboy is stupid, and that is what you're doing), but I was just airing my thoughts on the topic, which is what TFS asked for. If you can't possibly comprehend why someone would deign to suggest your glorious C++ is anything but the result of angels crying tears of code, here's one perspective on some of its issues; it's certainly not the only one of its kind (but it's more in-depth and better-written than anything I'd come up with in a comment on /.).

Right, and I'm currently working on a project where someone thought that template heavy code and functors everywhere without comments are the solution to everything.

The problem with C++ is that NOBODY knows how to use it. It doesn't straddle the line between functionality and readability very well, and programmers have somehow increasingly been skipping the part of their education that relates to commenting their damn code so the next poor bastard that comes along doesn't have to decipher everything from scratch.

A friend of mine (who now has a PhD in robotics and last I heard was working on autonomous vehicles) once said, "The philosophy of C++ is that you don't pay for anything that you don't use. The result is a language where there's nothing worth paying for." There are few times where the extra features of C++ don't come at a cost that's HIGHER than the benefit that they give, either syntactically or even in terms of performance.

Here's a page that runs down some of the most egregious problems with C++. It's broken by design. http://yosefk.com/c++fqa/defective.html

When I have been part of interviewing new hires, I've tended to ask this question: "what do you find frustrating about C++?"

If you really know C++, there are bound to be at least a few things that you find frustrating. The lack of standardisation on binary interfaces, the continued drive for flexibility at all costs (resulting in a million ways to do one simple thing) and the way they have ALWAYS emphasised pattern clutches over improving the language. Despite (or perhaps because of) the near-complete lack of ABI compatibility between versions, they nearly never remove or depricate anything in the the standard or the STL API, meaning any new "simplification" always comes in addition to the old way, it never replaces it. Sadly this means the standard is never actually simplified, they just add yet another layer of abstraction, which always leaks. Lots of the STL and the standard patterns used by C++ developers are really clever and I'm sure they were intensily satisfying to develop. But satisfying cleverness is not necessarily something to build a programming language on.

The worst part is that the patterns and algorithms which were developed to work around gaps in the core language actually become arguments not to improve the core language. Let's face it; as much as I've used std::for_each, it should never have existed. Instead, range-based for-loops should have been in way before C++11.

The c++ FQA sums up some of my own frustrations.

That said. There is no other language with such easy access to such a myriad of great libraries out there, especially for science/engineering/visualisation, and for this reason I cannot agree with the FQA's notion that there are no reason to start new projects in C++. By using these libraries, your own code could well become quite elegant and you would shoot yourself in the foot if you decided to avoid C++ on principle for a situation where C++ and its large set of libraries would solve your problem.

I find C++ much more fun, because it does exactly what I tell it to.

But you sometimes have to be a language lawyer to figure out exactly how templates, inheritance, the implicit conversion, and other C++ language features will interact in a given case. See C++ FQA Lite for a taste of the language lawyering that C++ programmers have to do in their heads to be competent in the language. In what way do you find this easier than figuring out the semantics of a particular dynamically typed language?

Python, PHP, Ruby

PHP is less strongly typed with its policy of playing loose with implicit conversions to and from numeric and string types. But Python is strongly (though dynamically) typed.

I normally hate most of the garbage that comes out of Kotaku, but this is a really good article. That said, it reminds me a lot of Yossi Kreinin's C++ FQA. A good chunk of the article is spent talking about how Doom 3's source is good code despite being bad C++. What kind of language is best written in a way frowned on by the C++ community? Absurd!

Objective-C++ is a COMBINED language with Objective-C and C++ and Objective-C itself is as much C as C++ is also C.

Objective-C is not bridging with some API, module, or library to talk with C code-- it IS C code. C++ and Objective-C both were made to bring OOP to C while KEEPING the C language; but they made different design choices up front. Objective-C was bigger on SmallTalk than C++ which just couldn't let go of obsessions over issues like the cost of runtime binding or making compiler authors suffer for decades... (BTW, a nice read http://yosefk.com/c++fqa )

Personally, I am still a fan of plain old C.

mindless fuckwads find themselves so consumed by their hateful delusions they end up doing things like writing a point-by-point rebuttal to the entire C++ FAQ.

FTFY

For a reasoned distaste of C++, see:
http://yosefk.com/c++fqa/defective.html

A proper distaste of C++ is best acquired by taking over a legacy C++ project.

If anything, the dislike for C++ from people who use C++ regularly is much deeper than the more casual dislike that C programmers have. C programmers just think C++ is too complex and unnecessary, but C++ programmers find themselves so consumed by their dislike they end up doing things like writing a point-by-point rebuttal to the entire C++ FAQ.

I think they're just more vocal. Not everyone hates C++. My job involves writing in C, C++, and C#. I love C++. In my ideal world, I'd have C++ with all the .net libraries (and no, managed C++ isn't that. C# is far preferable to writing in managed C++, as C# is actually a pretty good language and managed C++ doesn't give you any of the cool features of C++ that C# doesn't have).

I find people's arguments against C++ to be quite illogical. For example, one of the reasons I really like the language is because it can do true multiple inheritance. People everywhere will then immediately correct me with, "multiple inheritance is bad, mmk?" Then they'll back up that statement by talking about the diamond problem, and how I should use interfaces. I do use interfaces, but they're not a replacement for multiple inheritance because it's still forcing me to duplicate code when I wouldn't otherwise have to. Besides, the language handles the problem in a reasonable way (the order in which you define the inheritance matters), and, as a programmer, if you're inheriting from two classes that have a method with the same signature, then those methods should be virtual, and you should override the method to do exactly what you want. The diamond problem isn't this beast for which there is no reasonable solution. It's just something you need to be cognizant of when coding.

There's also the people who complain about all the incredibly hard to debug crazy stuff people do with templates. You're really just complaining about bad coding. Templates allow you to build more reusable code than generics, and that's how you should use them. If you're going beyond that just because they're turing complete and you can do more with them, well...you might as well complain about C after looking at last year's winner of the obfuscated C contest.

If anything, the dislike for C++ from people who use C++ regularly is much deeper than the more casual dislike that C programmers have. C programmers just think C++ is too complex and unnecessary, but C++ programmers find themselves so consumed by their dislike they end up doing things like writing a point-by-point rebuttal to the entire C++ FAQ.

In defense of PHP, Python and Ruby suck in their own ways too -- plain and simple. Maybe not as much, or in the same ways, but they still suck. Try them, and see for yourself; if you haven't seen why yet, it means you're doing it wrong or sticking to writing trivial code where they remain beautiful and all encompassing and what not.

In the case of Python, since it's on topic, try recent versions of Python's hex() function for instance. Assume it works like it does for other languages, and use it to shovel through a Core Dump and see how it works out for you -- it's not a pretty sight.

Just use whatever you're most comfortable with, and get your job done. Deliver, get paid, and get a life.

Cool and unusual things are *not* something to strive for

I never disagreed with that, I think that's bad programming.

and it's not what C++ is for.

No, but C++ makes such things possible more than most other languages.

Did you change the topic to Python now? I don't recall any such problem in C++.

That was an exaggeration. I was referring to problems like these.

Hence, sites like http://yosefk.com/c++fqa/

Many of the assertions on Yossi Kreinen's C++FQA page have been soundly refuted, and many more are simply opinions (or, less kindly, rants). As with any language, there are valid criticisms of C++; the FQA page is not the best place to go looking for reasonable discussions on such matters.

- T

Given that KDE and its applications are written in and married to C++ (and QT) I'm not surprised that few people want to contribute.

I know that C++ is the Big Thing and Right Thing in mainstream industry, but it is extremely complex with an enormous learning curve and huge demands on development resources, and developer time.

I, for one, certainly wouldn't contribute to a C++ project for fun. I only do it when I'm paid, and only if I can't avoid it.

Projects do not need, and should not want, contributors who are deterred by having to use a reasonably sane programming language. If writing C++ is enough pain to deter you, then you either are not a strong C++ programmer, or you are not committed to building something great. Probably both. Projects don't need everyone to be a contributor. They need a few contributors who are actually good programmers with time, resources, and motivation to build something great.

Given that KDE and its applications are written in and married to C++ (and QT) I'm not surprised that few people want to contribute.

I know that C++ is the Big Thing and Right Thing in mainstream industry, but it is extremely complex with an enormous learning curve and huge demands on development resources, and developer time.

I, for one, certainly wouldn't contribute to a C++ project for fun. I only do it when I'm paid, and only if I can't avoid it.

Yet another good reason to avoid C++.

Alternatively, you can read the C++ FQA:

http://yosefk.com/c++fqa/

its often slower C/C++, so the simple presence of the Java icon makes both programmers and users exasperated and annoyed.

After recent improvements in the VM, the only time it's noticeably slower than C++ is if the VM has to be started for the first time. If you run more than one program written in Java, it's less noticeable.

Thirdly, it is abstracted away from machine code

So is C++. In fact, some critics believe that wading through a rat's nest of C++ templates is so abstracted that it's harder to know what's going on in a program than it would be in Java.

So what? C has function pointers, so you can do it that way too, just like C++ virtual methods.

I've had the C++ brainwashing and used it for 5 years commercially. The more I learn about it, and the more language "improves" the more I laugh at it and the more I respect and admire C. Linus was right.

And don't get me started on exceptions, templates, iostream, references...

This is a good point of reference for C++ issues.

ObjC is not that friendly or easy, it sports some weird syntax, slow code (compared to plain C)

And C++ syntax isn't weird compared to plain C, too? Just because "everyone uses it" doesn't make it less weird. Templates are from another planet. Uh-oh, here comes a guy in a suit holding a flashy thing...

You're right. As anyone who's read C++ FQA by Yossi Kreinin might guess, C++ itself could be one of the culprits.

The trouble is that if you only have tiny steps available, then you have to figure out the original programmer's intention.

And figuring out programmers intention is easier when the languages grammar is more ambiguous... not.

Context-free understanding of what code does is _useful_ something that c++ completely blows out of the water once you start abusing its more advanced features.

Can c be coded badly? of course, can you sit down and figure out what a code snipped is doing? yes. Can you do the same of ill coded c++, quite possibly no, this is a serious flaw.

Well, undecidable grammar (example)r is certainly a lovely feature c++ has that c does not (sarcasm)

Even horrible c code can be understood if you just sit there looking at it for a bit. That in c++ it is possible for that to not be the case is a horrible failing.

Of course you can work around this, and people have been doing so for a long time. But it's one extra unnecessary annoyance, and it gets more and more complicated and annoying as programs grow more complex. As shutdown said, the preprocessor/macro system is brittle; we deal with all kinds of kludges (all the way from the simple #ifndef macro which has to wrap anything which might somehow get included twice to the many complexities of Autotools) to try to keep it working in complex situations. And there's really nothing to recommend it- you say having header files for everything encourages good design, but I don't see any reason this would be true; it's wasted effort, but people feel it must be a helpful ritual since they've been doing it so long.

It's true that with C89 and up, compilers try to provide implicit declarations for functions which you call before any prototype/declaration. But there are good reasons why this is still a warning; I don't know all the details, but there can be issues with the types the compiler infers for the implicit declaration and matching that to the actual function, and IIRC this gets a lot worse under C++. It's best to stick with the ritual of providing the prototypes first, and AFAIK getting rid of them would require a major language redesign and not just extra compiler smarts.

This is a good example of the general pattern- there are lots of suboptimal design decisions in C that require only a trivial amount of effort to work around for simple programs (the programs K&R were thinking about back in the day of the PDP-7), but the effort is still there; as programs grow in complexity, making sure these things are always dealt with correctly becomes far from trivial, and when you add new language constructs to the mix (esp. C++) you compound the problem.

This isn't unique to C; as any programming language ages, some of the design decisions and tradeoffs it originally made will turn out to have been suboptimal. If you add new features they often interact poorly with such suboptimal design decisions, creating complicated "gotchas"; the more powerful the new feature the more likely it is to have FQA-inspiring oddities and gotchas. (Example elsewhere: talk to a Java developer about how generics are done via type erasure and they'll likely have a story to tell about times they've banged their head against that and wished the thing had been done right from the beginning.) But the problems are more pervasive in C and C++ since so much has changed and so much has been learned since C was first designed.

A doc that needs to be read by more people is the C++ Frequently Questioned Answers.

Not really, that's just a lengthy rant by someone with a grudge, not much merit there.

Now C++ is the ultimate example of a design by committee language. And that committee is huge.

Huge indeed, but judging by the results, not particularly good.

A doc that needs to be read by more people is the C++ Frequently Questioned Answers.

C is not better than C++. Quite the opposite: Most (not all, though) of C++'s problems are actually C problems.

C++'s problem is that it tries to be all things to all people, and fails.

C++ started out trying to be a superset of C. That was the first mistake. They soon found out that it wouldn't work, but had to keep most of the C features for all that old C++ still to work.

People still try to pretend that it's a "good idea" to recompiled your C source in a C++ compiler (which involves a non-trivial porting effort that they sweep under the carpet) so that you can start to "benefit" from the new C++ features.

C++ syntax is terrible and they keep making it worse. Since they tried to keep it backwards-compatible with C (and failed) they tried all sorts of dirty hacks with the syntax to put in the new features.

The older I get, the more I'm convinced by using the right language for the job. If that means Java, Ruby, PERL, C or whatever, then so be it. C++ is not usually a good choice unless you have to work with and on existing C++ code.

A language I looked at when I was 15/16, which really taught me how to write good code was Modula-2. It's spirit lives on in Borland's Object Pascal/Delphi (whatever it's called nowadays).

For an entertaining and insightful look at many of the problems with C++, have a look at the C++ Frequently Questioned Answers which is organised like (and in response to) the C++ FAQ Lite.

Finally, here is a collection of links to various criticisms of C++.

In summary, C++ is too big and too complicated, and it keeps on getting worse.

You sound like someone who's read http://yosefk.com/c++fqa - which I highly recommend to anyone who hasn't seen it. I don't necessarily agree with 100% of it - but it is a very thorough critique of C++ and well worth reading if only to get a more rounded understanding of the language's flaws.

It's certainly true that many of these flaws can be worked around using some combination of RAII, Smart Pointers, Boost, QT and now C++0x features - but the point is you shouldn't have to deal with all this - proper high-level languages take all this off your hands.

So what do you make of this?

Many of us have to use C++ at work, but I'd never choose it for anything of my own. However, I'm lucky in that most of the code I deal with is in Plain Old C. It's a real-time embedded platform. The C parts are readable, maintainable and predictable. The C++ parts are "interesting." The source is a lot more verbose. I'm not sure what it achieves other than slower compile times and bigger object code.

If he really wants to go into creative writing, we might remind him that the 26 letters of the alphabet were good enough for Shakespeare.

Exactly. Completely Missing The Point at its best.

1. The idea behind modern programming is reducing complexity. That can't really be done by using symbols no other programmer has ever seen before.
2. Most programming fonts go out of their way to make those symbols look distinct. You simply have to know if that's a zero or an upper-case O. Imagine trying to figure out if that there is a Greek upper-case Omega or a "Dentistry symbol light down and horizontal with wave" (taken from TFA).
3. APL died for a reason.
4. Author cites C++ operator overloading as a good thing. 'Nuff said.

C++ FQA (frequently questioned answers)
(Defective C++ is a summary)

'There are only two things wrong with C++: The initial concept and the implementation' - and other quotes

Why C++ sucks

And, previsibly: http://cplusplussucks.com/

C++ FQA (frequently questioned answers)
(Defective C++ is a summary)

'There are only two things wrong with C++: The initial concept and the implementation' - and other quotes

Why C++ sucks

And, previsibly: http://cplusplussucks.com/

Sometimes it's easier and faster to code from scratch than it is to use off-the shelf software - especially in the age of "frameworks".

I like this take on it: redundancy is bad, but the primary way of avoiding redundancy, factoring things out into libraries or frameworks, introduces dependencies, which are also bad. Which is worse? Depends, but I think dependencies are worse in more cases than people believe. I personally like to depend on something only when it's a big enough chunk of code to be worth adding a dependency for, has a clean API, and has an active and interested maintainer.

you can always use nothrow new

As I understand it, the standard library uses throw new, not nothrow new. So if you use the standard library, you get the exception handlers linked in.

What is the performance overhead of namespaces, [...] references, [...] use of const ints for array sizes (more efficient than C), non-virtual methods, protected/private modifiers

True, these features allow one to use C++ as "a better C". But a lot of C++ fanboys will claim that if a program doesn't use virtual, throw, and <iostream>, it's not in the spirit of C++.

typesafe object creation, STL (the word "virtual" does not appear anywhere in the STL sources)

Exception overhead. Or is the entire C++ standard library also available in a nothrow version?

function and operator overloading

No runtime overhead, but especially operator overloading is easy for a programmer to do wrong. People see += and think "cheap"; they see .addAll (Java) or .extend (Python) and think expensive.

support for wide characters

Doesn't <wchar.h> aka <cwchar> have these too?

Many C++ programmers use printf instead of iostream.

I agree, but C++ fans who write things like C++ FAQ Lite section 15 disagree. See both sides of the story in C++ FQA Lite section 15.

Note that C++0x has features specifically designed to support a typesafe printf

That will be interesting once LLVM and GCC actually implement it. Have they yet?

if you remove the templates by hand-instantiating them, you'd still have the same issue of code duplication.

The difference is that algorithms and containers in C or Java encourage the use of erasure to a higher type (e.g. void * or java.lang.Object). C++ templates can be used this way, but they can also be instantiated once for each T* (by pointer) or even once for each T (by value). I can think of a few things to watch out for when using templates:

• Templates make compiler error messages hard for the programmer to read.
• The ability to instantiate templates multiple times tempts the programmer to make unproductive time/space tradeoffs that might be hard for other programmers to find and fix.
• Template containers that hold objects by value introduce a risk of slicing when used with STL containers.

So some people aren't big fans of C++ templates because templates are so easy to misuse.

C++ only becomes slower if you use certain features that have a performance impact.

And virtually every useful feature of C++ that is not in its common subset with C is one of those.

What is the performance overhead of namespaces, typesafe object creation, references, function and operator overloading, use of const ints for array sizes (more efficient than C), non-virtual methods, STL (the word "virtual" does not appear anywhere in the STL sources), support for wide characters, protected/private modifiers, etc.? While features like templates and metaprogramming have performance tradeoffs, skilled programmers can use them to make programs that are faster than the corresponding C programs.

Example: if you use exceptions, there is a performance penalty.

And if you use operator new, you use exceptions.

Firstly, this whole point is spurious because you can always use nothrow new, which was put in the standard precisely for people who want exception-free code.

Secondly, the (exception-throwing version of) new may well be faster at error handling than malloc. For the very many programs that only catch allocation errors at the top level, setting up the exception handler is just negligible part of startup costs and far faster than checking the return value from each malloc for zero.

Even if you are doing fine-grained error checking around each call to new, it's not clear whether setting up the exception handler is slower than checking for a null-returrn. It is certainly far less error-prone.

The main slow downs you will see in your average C++ program, over the corresponding C, is the use of the string class

That and <iostream>. Once, I tried programming in GNU C++ for a system with an ARM7 CPU and 288 KiB of RAM. Even after applying all the link-time space optimizations I could find, Hello World statically linked against GNU libstdc++'s <iostream> still took 180 KiB. (Dynamic linking wouldn't even have worked because libstdc++.so itself is bigger than RAM.)

Many C++ programmers use printf instead of iostream. You're perfectly free to use whichever you want, depending whether you are more concerned with code size/performance or type-safety/extensibility.

Note that C++0x has features specifically designed to support a typesafe printf, which will completely own the very type-unsafe C version.

Furthermore, C++ templates allow code re-use with exactly 0 performance loss

As I understand it, C++ compilers implement templates by making a copy of the object code for each type for which the template code is instantiated. Once you instantiate a template numerous times, your binary gets bigger, and it slows down because it has to keep loading data from storage instead of caching it in RAM. This hurts especially on handheld platforms such as the Nintendo DS, which has only 4 MiB of RAM.

I agree that Nintendo DS programmers should limit their use of templates. Not sure why the many programs which are not targeted at the Nintendo DS (Even the DSi has 4 times as much memory) shouldn't be able to generate the far-faster code made possible by template programming (See the "Was it Worth It?" section here).

Frankly, there is no valid reason for starting a new program in C in this day and age.

This is true but only

C++ only becomes slower if you use certain features that have a performance impact.

And virtually every useful feature of C++ that is not in its common subset with C is one of those.

Example: if you use exceptions, there is a performance penalty.

And if you use operator new, you use exceptions.

The main slow downs you will see in your average C++ program, over the corresponding C, is the use of the string class

That and <iostream>. Once, I tried programming in GNU C++ for a system with an ARM7 CPU and 288 KiB of RAM. Even after applying all the link-time space optimizations I could find, Hello World statically linked against GNU libstdc++'s <iostream> still took 180 KiB. (Dynamic linking wouldn't even have worked because libstdc++.so itself is bigger than RAM.)

Furthermore, C++ templates allow code re-use with exactly 0 performance loss

As I understand it, C++ compilers implement templates by making a copy of the object code for each type for which the template code is instantiated. Once you instantiate a template numerous times, your binary gets bigger, and it slows down because it has to keep loading data from storage instead of caching it in RAM. This hurts especially on handheld platforms such as the Nintendo DS, which has only 4 MiB of RAM.

Frankly, there is no valid reason for starting a new program in C in this day and age.

This is true but only technically, because most of C is also contained in C++.

So they switched from a sensible programming language to language that is fundamentally broken and to a build system that is incomprehensible for human beings? Wow, what an upgrade!

CAPTCHA: Virtual... How fitting.

It's not that it's bloated or slow. It's that it's retarded and misdesigned. It's as if C was reinvented with slightly different semantics for no real benefit.

So, if you present FAQ, I have to counter it with FQA.