People keep asking me what my opinion of C++ is. Since I'm a C and C++ programmer, I have a lot of experience with the language, and I do think about it from time to time. So I just want to write it down, once and for all. If you're still interested, prepare for a long and somewhat self-indulgent post.

C++ is a product of the mainstream software industry in the 1990s. At that point in time, C was the standard language of programming-- the one that kids learned in college, and people wrote most software in. 

C had a problem though-- developing software in C was relatively slow. That was a problem for a lot of companies. Often the first company to bring a product to market had a critical advantage in the marketplace, even if that product had serious flaws. So there was a need for a language higher level than C, but which could leverage the existing base of C programmers and C code. Enter C++.

The main design goals of C++ were compatibility with existing C code, "reasonable" execution speed, and rapid development. It met those goals spectacularly. A truly good C++ programmer can crank out code at pretty high speed, which will have acceptable performance. Projects were often converted from C to C++, incrementally.

However, two decades after the language first appeared, the situation is different. The requirement that programmers master C before learning C++ is a big problem . A lot of kids graduate from college with only minimal exposure to C. Even if you are a good C programmer, though, you will find that C++ is complex and unforgiving. There are a lot of unwritten rules that you *must* remember to avoid getting burned. Similar to perl, there are a lot of features that got put into the language without enough thought. These misfeatures (like default parameters for functions, and throw specifications enforced at runtime) must be avoided!

More fundamentally, in general, C++ has extremely poor "mental locality." It's easy to make changes to a codebase that seem innocent, but which have far-ranging repercussions. For example, changing the order of global variables within a file will cause one to be initialized before another at global constructor time. That, in turn, may cause a third object to fail during initialization in a seemingly mysterious way. Operators can be overloaded, which makes even the simplest-looking mathematical expression a potential quagmire of complexity. Leave out an ampersand, and a huge object may be copied instead of passed by reference. You may never know where your performance is going until you profile. The bottom line is that unless you are deeply familiar with a project, looking at a diff with 3 lines of context is usually not going to tell you much about how a change affects the codebase.

Moreover, each C++ programmer has his own style, which is different from other programmers. Does he use exceptions? How about RTTI? Does he use namespaces, or file-static functions? Does he use std::tr::shared_ptr, or a hand-rolled version? Or does he use auto_ptr? How much does he know about template metaprogramming?

The huge amount of undefined behavior present in the language makes analyzing the behavior of code extremely difficult, even for experienced programmers.

However, in order to hit that perfect trifecta, serious compromises were made. Writing a C++ parser is legendarily difficult. The language is complex and unforgiving of mistakes.




It's very diffu

A change in one file in the project can 

A good C++ coder can crank out code at a really remarkable rate.