By Stephen R. Davis

You’ll quickly come to appreciate that C++ is about as picky as a judge at a spelling bee. Everything has to be just so, or the compiler won’t accept it.

Interestingly enough, it doesn’t have to be that way: Some languages choose to try to make sense out of whatever you give it. The most extreme version of this was a language promulgated by IBM for its mainframes in the 1970s known as PL/1 (this stood for “Programming Language 1”). One version of this compiler would try to make sense out of whatever you threw at it.

Some nerds (who shall remain nameless) used to get immense fun during late nights at the computer center by torturing the compiler with a program consisting of nothing but the word “IF” or “WHILE.” Through some tortured logic, PL/1 would construct an entire program out of this one command.

The other camp in programming languages, the camp to which C++ belongs, holds the opposite view: These languages compel the programmer to state exactly what she intends. Everything must be spelled out. Each declaration is checked against each and every usage to make sure that everything matches. No missing semicolon or incorrectly declared label goes unpunished.

It turns out that the “tough love” approach adopted by C++ is actually more efficient. The problem with the PL/1 “free love” approach is that it was almost always wrong in its understanding of what is intended. PL/1 ended up creating a program that compiled but did something other than what was intended when it executed. C++ generates a compiler error if something doesn’t check out — to force you to express your intentions clearly and unambiguously.

It’s actually a lot easier to find and fix the compile time errors generated by C++ than the so-called runtime errors created by a compiler that assumes it understands what you want but gets it wrong.