Base and Derived Classes in C++

When you define a class, the language is willing to supply copy and move operations for you. For a simple, self-contained class, letting those defaults do the work is often reasonable. Inside a class hierarchy, however, the same shortcut can quietly go wrong. This article looks at why the default behavior breaks down once a base class and its derived classes are involved, and what the usual remedy is.

The mistaken belief this article targets is that default copy and default move operations work correctly for a class that sits in a hierarchy. The belief is easy to hold, because the defaults work well in ordinary cases. The source describes the situation as typically a disaster, so the belief is worth testing before you rely on it.

The key idea is about knowledge. The default copy and move operations are generated for the class in which they appear. A default operation for a base class therefore reflects only the base class's members. It has no way to reach members that exist only in a derived class. This is the core reason the defaults cannot be assumed correct in a hierarchy.

The problem is not that the derived object lacks the extra members. The object really does have them, and a faithful copy would have to account for them. The difficulty is that the base class's default operation was written with only the base class in view. Whatever it copies, it copies from the base class's own list of members.

Think of the base class as a description of what every object in the family has in common. The derived class adds details that only some family members have. A default operation written from the base description can handle the shared details, but it has no vocabulary for the extra details, because the base description never mentions them.

A pointer's declared type tells you what the pointer can see. A pointer to a base class gives you access to the base class's view of the object, and nothing more. The derived class may add members of its own, but code that holds only a base pointer has no information about them. When a copy or move must duplicate the whole object, the operation needs to know every member it has to duplicate. Through only a base pointer, that knowledge is missing.

Read this diagram as a statement about visibility. The object really does have derived members, and a copy must account for them. But the code that holds the base pointer can reach only the base members, so a default operation working from that view has no basis for copying the derived part correctly.

Follow one default copy from start to finish. Code holding a base pointer asks for a copy. The default copy operation for the base class runs, and it works only with the members the base class declares. It can copy those members. It has no route to the derived members, so the copy that results cannot be a correct duplicate of the whole object.

The same limitation shows up when a derived object is copied directly into a base-class object. The example below is an original illustration written for this article, not taken from the source. It uses a base class with one member and a derived class that adds a second member.

The derived member extra is the part that does not survive. The base object is a smaller object than the derived one, and the base class has no place to keep what it was never told about. This is the same knowledge gap described earlier, now visible in a concrete copy.

Given the problem above, the source gives a direct recommendation: the best thing to do is usually to delete the default copy and move operations. Deleting them means eliminating the default definitions of those two operations for the class. The hierarchy then no longer offers a default copy or move that would silently do the wrong thing.

Notice that the recommendation names both operations. Copy and move are handled together because both face the same limitation: each needs to know the derived members in order to duplicate or transfer them. Deleting only one of the two would leave the other default in place to fail in the same way.