Accessing Derived Class Member Functions

Imagine a program that works with many kinds of shapes. It has a function that reads a shape from somewhere and hands it back to the caller. The caller does not need to know exactly which kind of shape it received. It only needs to treat the value as a Shape. This is a useful design, because the rest of the program can handle every returned object through one common interface.

That convenience comes with a cost. Once a value has been returned as a Shape pointer, the compiler only sees the Shape interface. Any member function that exists only in a derived class is no longer visible through that pointer, even when the object really is of that derived type. This article follows one such pointer step by step and shows how to safely reach the derived class function when it is needed.

Suppose a program has a function called read_shape() that returns a Shape pointer. The function does not promise which kind of Shape it has in hand. It might be a plain shape, a circle, or a Smiley. Because the return type is Shape, the calling code sees every result as a Shape and nothing more specific.

Now follow one returned value. The moment read_shape() returns, the variable in main holds a Shape pointer. If that object is really a Smiley, the object is a Smiley, but the variable only offers the Shape interface. Every step after this point depends on that one fact: the pointer's declared type is Shape, while the object's actual type may be something more specific.

Consider the Smiley class, which provides a member function named wink(). A Smiley is a kind of Shape, so a Smiley object can be stored and passed around as a Shape pointer. But when the code holds only a Shape pointer, it cannot simply call wink() on it, because wink() belongs to the Smiley part of the interface, not the Shape part.

The diagram shows the key idea. The pointer type exposes the Shape interface, and wink() sits outside that interface. The object itself has both parts, but the pointer only gives access to the part its declared type names.

The derived part is still present in the object. The pointer type simply decides what the compiler allows you to reach through that pointer. So the problem is not that the Smiley part is missing. The problem is that the variable's declared type does not give you a path to it.

This raises the central question: what can we do when we need a function that only one particular derived class provides? The source answers it by asking a direct question about the object at runtime. Is this Shape a kind of Smiley?

The dynamic_cast operator asks at runtime whether a Shape is a kind of Smiley. It is written as a cast to a Smiley pointer. Read the line as the question itself. The variable shape is the Shape pointer. The dynamic_cast asks whether that object is a Smiley. The result is then stored in a Smiley pointer, which gives the program a way to reach Smiley-specific members if the answer is yes.

The cast is best thought of as a question with two possible answers, not as a guaranteed conversion. The answer is not always yes. A Shape pointer might refer to a plain shape or a circle, and in those cases the question has a no answer. Testing the result before using it is the safe pattern.

The diagram shows that the program makes a decision at the point where the type check happens. Only the yes branch leads to wink(). The no branch leads away from Smiley-specific code entirely.