Item 38: Never redefine an inherited default parameter value.

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);
pr->draw(RED);
// calls Circle::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.