The Dark Side of C++ (2007)

Again the operator overloading thing.

Yes, it's true. && might do something different than you might expect if you're a C programmer. If you're a C++ programmer, then you know somebody might have overloaded the && operator. Yes, they could do it in some weird and unexpected way. Just like somebody can declare a weird and unexpected macro in C.

Yes, people who define C++ classes you use can screw you with dangerous or incorrect behavior, like throwing exceptions from destructors. Just like people who write C libraries can screw you with dangerous or incorrect behavior.

auto_ptr is not useless. At least, I assume it's good for something. Who knows? If not, who cares? boost::shared_ptr is "poor man's garbage collection," not auto_ptr. If you cite the documented behavior of a type as a huge and unwelcome surprise, then gosh, I know exactly how to avoid surprises like that: read the freaking documentation before you use the type.

Oh, and again with the "I can't tell what this code does." Here's a crazy scenario in C: call a function. Do you know what the code does? No, you don't. How awful! Unless you look at the function you just called, or maybe just glance at its documentation.

Half of these criticisms of C++ boil down to, "It's okay for functions to have unknown behavior that I have to learn about before using them, because I'm used to that, but it's not okay for types to have any kind of unknown behavior, because I'm used to C, where that is not the case."

I have to disagree with some of the "warts":

operator[] adds a member to a map if it does not already exist

The main theme of this article seems to be "C++ gives you too much flexibility," but this is a case where C++ is enforcing a default behavior and limiting your flexibility. In Python, for example, understanding code that queries for a key in a dictionary requires you to know some context about whether that dictionary has a default value for missing keys. For all the quibbling the OP does about operator overloading, I'd expect him to be grateful for the predictable nature of map's operator[].

local static initialization is not thread safe

This is just wrong: http://stackoverflow.com/questions/1270927/are-function-stat...

Firstly, half of the time the guy bitches about flaws with the compiler, and not the languages (Page 0 to 6).

Most of the bitching is about language features which exist. If you don't like auto_ptr then DON'T use auto_ptr! C++ at least allows you to ignore features without paying a penalty. Which is why it has a virtual keyword; and does not make every method virtual like Java.

The at() versus operator[] is also an example of the above: bounds checking can get expensive in a tight loop.

It seems that the author has never seen a large, well-written C++ project. In fact, that is the case with many such C++ bashers (I used to be one too). Once one sees how C++ makes it easy to manage a 500000 line project, they will probably think again.

Many good criticisms, mixed with some bad.

Exception safety is achievable (pthread_mutex_lock example) if you wrap resources with RAII classes. If he called this "difficult to use C libraries while retaining exception safety" it would be more accurate.

The iterator criticisms are applicable to C iterators too (represented by pointers or user objects).

The various things `baz = foo->bar(3)` could mean are interesting. Some of them are reasonable, if you assume some sort of consistency. It may make audits hard, but the fact it might use implicit cast converters there should not make it harder to read if you are allowed to make the most basic assumptions about what an automatic cast operator would do.

I enjoyed it, nonetheless.

Some of the examples at the end are laughable.

    If new[] throws an exception, this leaks 
    a file handle and deadlocks the next caller.

Poorly written code is buggy? No shit, Sherlock! — to paraphrase the OP.

The Frequently Questioned Answers has good, insightful criticism of C++ is here: http://yosefk.com/c++fqa/

BTW: The errata: http://www.fefe.de/c++/

> With C++, you don’t see the writes, because it says `some_func(whatever,the_int,SOME_FLAG);` and it can still write the_int if it’s a reference. In C, it would be &the_int, which is easily recognizable.

I don't understand why people do this. C++ has not abolished pointers; it's still possible to require the &, and it increases readability considerably; why ever use references (to value types; objects are different) as function parameters?

I tend read all "C++ is (bad|good)" lists and it never occurred to me to look at operator overloading as something inherently bad, something that sacrifies the clarity of the code for its brevity (see page 23 and onward). This is an excellent angle... but not that I would prefer C++ to not support overloading.

Many of the complaints have become irrelevant or at least much less relevant with C++11 and huge progress also on the compiler side (most notable clang but for example GCC also has improved many of the unreadable error messages).

> Iterator to stale element (resized vector, or balanced tree after rebalance)

I don't think that rebalancing the tree invalidates iterators (other than the deleted element [if any] that is)

After seeing some of those rants, especially after the namespace-hatred, I wonder if they'd prefer a flavor of Assembly. Apparently they hate many common methods of simplifying and organizing code - clearly, things like virtual methods should always look different than non-virtual methods, namespaces are pointless when you can `gl_open`, and all macro-like functionality is simply obfuscation.

Most, if not all, of his arguments were already beaten to death. The rebuttal should be floating around somewhere on the Internet, but I couldn't find it with a quick search right now.

Anyways, right at the beginning of the presentation you see the quality of his arguments as he uses a very known problem of a particular compiler (GCC) to bash the language. Sort of a straw man fallacy.

> x[0] -= x[1]; // x[1] adds sizeof(bar) here, not sizeof(foo)

This code doesn't even compile?? What is the author trying to show with this example?

Please flag this article. Why do we feel the need to discuss how much C/C++ rocks/sucks repeatedly? HN should frown upon bikeshedding more than it does.

If I wanted an echo chamber, I'd be on Reddit.