Making Template Methods Too Flexible (10/15/2009)
(...) . . if( hook1() ) { // . (...)

Calling Virtual Functions in Constructors and Destructors (10/15/2009)
(...) .D x; // no resources seized or released! As the first step in the initialization of x, the derived class constructor invokes the base class constructor, which in turn makes a virtual function call to seize. As the last step in the destruction of x, the derived class destructor invokes the base class destructor, which in turn makes a virtual call to release. (...)

define Literals in C plus plus (10/15/2009)
(...) The #define directive does not respect scope. Most C++ facilities are now encapsulated in namespaces. This has a number of benefits, not the least of which is that different facilities are less likely to interfere with each other. (...)

define Pseudofunctions (10/15/2009)
(...) . . Here, we've committed the common error of insufficient parenthesization of the pseudofunction. (...)

for Statement Debacle in C plus plus (10/15/2009)
(...) . . It's generally a good idea to restrict the scope of a variable to the region of the program in which it's used. (...)

Excessive Commenting (09/21/2009)
(...) The line should originally have been written without a comment: a = b; The code is maximally clear as it stands, with no comment to be incorrectly maintained. This is similar in spirit to the well-worn observation that the most efficient code is code that doesn't exist. The same applies to comments: the best comment is one that didn't have to be written, because the code it would otherwise have described is self-documenting. (...)

Magic Numbers in C (09/21/2009)
(...) (If we had any concern about safety and correctness, we'd use a standard vector.) The trouble is that we're now obliged to examine every source file that uses Portfolio for each occurrence of the literal 10, to decide if that 10 means maximum number of contracts. Actually, the situation can be worse. (...)

Misunderstanding References in C plus (09/21/2009)
(...) (Though the C++ standards committee has discussed allowing references to references in the future, at least in some contexts.) int &&rri = ra; // error! int &*pri; // error!int &ar[3]; // error! References can't be const or volatile, because aliases can't be const or volatile, though a reference can refer to an entity that is const or volatile. An attempt to declare a reference const or volatile directly is an error: int &const cri = a; // should be an error . (...)

Ignorance of Base Language Subtleties in C plus plus (09/21/2009)
(...) If val is a function, this is of little importance. However, if val is a preprocessor macro, the presence of multiple expansions may produce incorrect side effects. In these contexts, the availability of an effective conditional operator as a substitute for an if-statement can be essential. (...)

Precedence Problems in C plus (09/21/2009)
(...) A left-associative operator like + will bind first with the argument to its left. Therefore, we'll first add a and b before adding the result of that subexpression to c. Assignment is right-associative, so we'll first assign the result of a+b+c to a, then assign a to b. (...)