Who's the intended audience?

Another Collection of C++ Advice

Stephen C. Dewhurst: C++ Common Knowledge
2005,Addison-Wesley, ISBN 0-321-32192-8, 250 pages
reviewed by Conrad Weisert, July, 2005, ©Information Disciplines, Inc.

Author's response

At first you might think this set of 63 articles ("items") is another collection of recommended programming practices, like the respected volumes by Scott Myers and Joshua bloch. On further examination, however, you note a fundamental difference. While Myers and Block emphasize good programming practice Mr. Dewhurst tells us mostly how things work. Unfortunately, he doesn't do that very well.

Strong start and short shrift

Item 1, "Data abstraction", made a strong favorable impression. It begins (p. 1) with a warning against an all-too-common bad practice:

"Never, ever, simply provide a bunch of get/set operations on the data members of [a class]."

Readers of this web site know that I've been campaigning against just that deplorable but growing practice, so I was delighted by Mr. Dewhurst's concurrence, even if he didn't really explain it.

The titles of next three items are startlingly broad:

Polymorphism
Design Patterns
The Standard Template Library

raising the readers' expectations. Unfortunately, there's not much to those items. What can one say in three pages?

Unexplained motivation

Mr. Dewhurst introduces highly specialized techniques with no explanation at all of why one would need or want to use them. For example:

The single-page article, Item 32, presents a technique for "Preventing Copying" of objects of a given class, but says nothing about the circumstances that make copy-inhibiting necessary or desirable.
Item 36, "Class-Specific Memory Management" begins (p. 123):
"If you don't like the way standard operator new and operator delete are treating one of your class types, you don't have to stand for it."
but gives the reader no clue as to why one might not "like" the standard operations' behavior or what advantages a user-defined alternative might offer.

Errors

The author notes in the preface (p. xii) the need for rigor:

"The author's ignorance of these complexities could result in an uninformed description that could mislead the reader …"

leading us to expect the most careful attention to accuracy. But then:

To illustrate a function with state memory, Mr. Dewhurst introduces the tired Fibonacci series example (item 18, P. 63), and then shows us this usage:
```
     cout << "next two in series: " << fib() 
          << ' ' << fib() << endl;
```
falling into the very trap that other writers take pains to warn against. Which call to fib in the same expression will your compiler evaluate first? Take your chances.
The curious reader will wonder about this function that appears to yield no result (item 6, p. 17):
```
 void average( int ary[12] );
     
```
Near the end of Item 13 "Copy operations" (p. 47) Mr. Dewhurst offers this advice:
"It's often necessary for correctness, and occasionally more efficient, to perform a check for assignment to self, that is, ensure the left side (this) and right side . . of the assignment have different addresses."
In fact, the accompanying code he recommends here is rarely if ever necessary or desirable, and may sometimes lead to a less efficient implementation. See Assignment to Self Overkill .

Those are minor goofs, but once the reader's trust is undermined he or she is likely to be skeptical of the author's other examples, especially those with vague explanations.

Last modified July 10, 2005