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:

  1. Polymorphism
  2. Design Patterns
  3. 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:

  1. 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.

  2. 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:

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.

Not recommended


Return to book reviews.
Return to table of contents.

Last modified July 10, 2005