Effective C++, 2E | Item 38: Never redefine an inherited default parameter value Back to Item 37: Never redefine an inherited nonvirtual function.
Continue to Item 39: Avoid casts down the inheritance hierarchy.
Item 38: Never redefine an inherited default parameter value.
Let's simplify this discussion right from the start. A default parameter can exist only as part of a function, and you can inherit only two kinds of functions: virtual and nonvirtual. Therefore, the only way to redefine a default parameter value is to redefine an inherited function. However, it's always a mistake to redefine an inherited nonvirtual function (see Item 37), so we can safely limit our discussion here to the situation in which you inherit a virtual function with a default parameter value.
That being the case, the justification for this Item becomes quite straightforward: virtual functions are dynamically bound, but default parameter values are statically bound.
What's that? You say you're not up on the latest object-oriented lingo, or perhaps the difference between static and dynamic binding has slipped your already overburdened mind? Let's review, then.
An object's static type is the type you declare it to have in the program text. Consider this class hierarchy: enum ShapeColor { RED, GREEN, BLUE };

// a class for geometric shapes
class Shape {
public:
// all shapes must offer a function to draw themselves
virtual void draw(ShapeColor color = RED) const = 0;

...

};

class Rectangle: public Shape {
public:
// notice the different default parameter value - bad!
virtual void draw(ShapeColor color = GREEN) const;

...

};

class Circle: public Shape {
public:
virtual void draw(ShapeColor color) const;

...

};


Graphically, it looks like this:
Now consider these pointers: Shape *ps;                      // static type = Shape*

Shape *pc = new Circle;         // static type = Shape*

Shape *pr = new Rectangle;      // static type = Shape*


In this example, ps, pc, and pr are all declared to be of type pointer-to-Shape, so they all have that as their static type. Notice that it makes absolutely no difference what they're really pointing to their static type is Shape* regardless.
An object's dynamic type is determined by the type of the object to which it currently refers. That is, its dynamic type indicates how it will behave. In the example above, pc's dynamic type is Circle*, and pr's dynamic type is Rectangle*. As for ps, it doesn't really have a dynamic type, because it doesn't refer to any object (yet).
Dynamic types, as their name suggests, can change as a program runs, typically through assignments: 
ps = pc;                        // ps's dynamic type is
// now Circle*


ps = pr;                        // ps's dynamic type is
// now Rectangle*


Virtual functions are dynamically bound, meaning that the particular function called is determined by the dynamic type of the object through which it's invoked: pc->draw(RED);                  // calls Circle::draw(RED)

pr->draw(RED);                  // calls Rectangle::draw(RED)


This is all old hat, I know; you surely understand virtual functions. (If you'd like to understand how they're implemented, turn to Item M24.) The twist comes in when you consider virtual functions with default parameter values, because, as I said above, virtual functions are dynamically bound, but default parameters are statically bound. That means that you may end up invoking a virtual function defined in a derived class but using a default parameter value from a base class: pr->draw();                     // calls Rectangle::draw(RED)!


In this case, pr's dynamic type is Rectangle*, so the Rectangle virtual function is called, just as you would expect. In Rectangle::draw, the default parameter value is GREEN. Because pr's static type is Shape*, however, the default parameter value for this function call is taken from the Shape class, not the Rectangle class! The result is a call consisting of a strange and almost certainly unanticipated combination of the declarations for draw in both the Shape and Rectangle classes. Trust me when I tell you that you don't want your software to behave this way, or at least believe me when I tell you that your clients won't want your software to behave this way.
Needless to say, the fact that ps, pc, and pr are pointers is of no consequence in this matter. Were they references, the problem would persist. The only important things are that draw is a virtual function, and one of its default parameter values is redefined in a subclass.
Why does C++ insist on acting in this perverse manner? The answer has to do with runtime efficiency. If default parameter values were dynamically bound, compilers would have to come up with a way of determining the appropriate default value(s) for parameters of virtual functions at runtime, which would be slower and more complicated than the current mechanism of determining them during compilation. The decision was made to err on the side of speed and simplicity of implementation, and the result is that you now enjoy execution behavior that is efficient, but, if you fail to heed the advice of this Item, confusing. Back to Item 37: Never redefine an inherited nonvirtual function.
Continue to Item 39: Avoid casts down the inheritance hierarchy.