Effective C++ is built around 50 rules or guidelines: "50 Specific Ways to Improve Your Programs and Designs." These pieces of advice concentrate primarily on the aspects of C++ that distinguish it from ordinary C. The book covers classes, templates, inheritance, virtual functions, etc., as you might expect from any book on C++ — but it also provides more general advice, such as in Item 1: "Use const and inline instead of #define." This collection of 50 essays, each illuminating a design situation in C++, is both readable and thought provoking, but you might not want to read it on a dark stormy night.

• Use new and delete instead of malloc and free.
• Check the return value of new.
• Avoid hiding the global new.
• List members in an initialization list in the order in which they are declared.
• Make destructors virtual in base classes.
• Use const whenever possible.
• Avoid overloading on a pointer and a numerical type.
• Never return a reference to a local object or a dereferenced pointer initialized by new within the function.
• Make sure public inheritance models the "is-a" relationship.
• Never redefine an inherited nonvirtual function.
• Prefer compile-time and link-time errors to run-time errors.
• Read the Annotated Reference Manual.

Item 42, "Differentiate between inheritance and templates," illuminates this issue by considering two class specifications that are similar in some respects but require radically different implementations. The first specification calls for stacks of simple data objects, such as ints, floats, or complex numbers. The second specification calls for a collection of cats.

Meyers shows that the difference in implementing such classes involves the realtionship between each class's behavior and the type of object being manipulated. The ints, floats, or complex numbers all behave identically as they are pushed on and popped from the stack, but Meyers's cats behave in ways specific to their breed — apparently a Tabby does not behave like a Persian or a Manx, as it comes out of storage. Since the type of cat affects the behavior of the class, inheritance is called for.

So the designer should ask, "Does the type of the object affect the behavior of the class?" Only when the type has no effect is the template appropriate.

char *GREETING      = "Hello";
const char *GREETING    = "Hello";
char * const GREETING   = "Hello";
const char * const GREETING = "Hello";

All programmers use const when the compiler forces them to do so, and most will use constants when the merits are obvious. According to Meyers, that attitude is far too passive. Thus Item 21 is entitled "Use const whenever possible."

Several benefits accrue. For example, functions whose declarations are identical except for "constness" can be overloaded. More important, declaring const prevents things from changing that shouldn't. It may stop some other part of the program from un-anchoring a pointer, or prevent a strange program from blowing away a reference.

This rule fits in with one of the book's general themes, which is to make the compiler do the work for you. Meyers starts early on this theme with Item 1 "Use const and inline instead of #define."

#define COR_FACTOR 32.3607

const float COR_FACTOR = 32.3607;

At first glance, it may not be obvious how to convert the following #define statement to a const, because it involves a character string:

#define GREETING "Hello"

const char * const GREETING = "Hello";

In discussing this item, Meyers points out that the interface, which declares the external form by which the member function is accessed, is always inherited. The designer can only choose whether or not to allow the implementation (the executing code) to be inherited.

Item 37 warns, "Never redefine an inherited nonvirtual function." Meyers explain why, much better than I can in this space. Briefly, what is true of a publicly inherited class should also be true of a descendant (because public inheritance means "is-a." See Item 35). A descendant that redefines the (statically bound) behavior of the ancestor breaks the "is-a" relationship. So with Item 37's restriction on redefinition, it turns out that a nonvirtual function is something of a special case. The nonvirtual member function is "invariant over specialization."

Some of us who were early C++ programmers used virtual only when we knew we had to, on behalf of some descendant class. We thought we were being efficient by avoiding overuse of virtual, but in reality we were throwing obstacles in the way of future sub-classing. A function that is left nonvirtual imposes a complication that prevents descendant functions from safely changing the behavior. A better rule of thumb might be "Always make member functions virtual unless there is a specific reason to constrain the behavior of descendants."

Under the heading, "Specific Ways to Improve Your Programs and Designs," the book colorfully illustrates by example lots of subtle wrong moves to avoid in C++. Vampire-like "memory leaks" arise from improper coordination between allocation and de-allocation of dynamic memory. Because memory leaks are not compiler-recognized errors, they slip right out past your debugger into run tune, where they suck the life from your executables. Failing to delete a pointer in a destructor gives rise to "a slowly growing cancer that will eventually devour your address space." If you re-define a nonvirtual function in a descendant class, "objects will likely exhibit schizophrenic behavior." Anytime you write a function, "aliasing can crop up in any number of nefarious disguises" (See Item 17).

Title: Effective C++ (50 Specific Ways to Improve Your Programs and Designs)
Author: Scott Meyers
Publisher: Addison-Wesley
Price: $25.75
ISBN: 0-201-56364-9