Comparison and Inheritance We continue last week's discussion of comparison functions by thinking about how to compare objects from different parts of an inheritance hierarchy.



We continue last week's discussion of comparison functions by thinking about how to compare objects from different parts of an inheritance hierarchy.

Suppose we have a Vehicle class from which we have derived Car , Truck , and other classes such as Airplane . How do we go about defining comparisons between objects of these various classes that will meet the C++ ordering requirements in a useful way?

Implementing these comparisons will have its own problems, because C++ objects are not polymorphic by themselves. To take advantage of polymorphism in C++, we must use pointers or references, perhaps directly, or perhaps through some kind of smart pointer class. Nevertheless, it is probably useful to think about the characteristics that such comparison functions might have before we worry about the details of implementing them.

The obvious problem in defining such operations is that there might well be an obvious strategy for comparing one Car with another, or one Truck with another — but it might not be obvious how to extend this strategy to allow comparing a Car with a Truck . For example, every Car might have a serial number, and every Truck might have a serial number, but these two kinds of serial numbers might be in completely different formats.

One's first temptation might be to use the obvious methods of comparing serial numbers between two objects of the same type, and then to say that two objects of different types are unrelated. In other words, define the < operation on two Vehicle objects to return false unless the two objects have the same type. In that case, < should compare the objects' contents (serial numbers, or any other of the objects' aspects we might choose).

This strategy is a disaster. To see why, consider two Car objects c1 and c2 , and a Truck object t . Under this definition, c1 is unrelated to t , t is unrelated to c2 , but one of c1 < c2 and c2 < c1 will be true. This behavior violates the C++ rules for order relations, because the unrelated operation is not transitive. In effect, when you're designing a comparison function, you should think of unrelated as meaning conceptually equivalent .

With this insight, let's revisit our original problem: We know how to compare two Car s, we know how to compare two Truck s, and we need to figure out how to compare a Car with a Truck . We can imagine this problem as if we had two stacks of cards, representing Car s and Truck s, respectively, and we want a way to shuffle these stacks of cards together into a single stack, while still preserving the ordering within each of the original stacks.

If the problem is described that way, it should be obvious that the easiest way to solve it is to put one stack on top of the other. Translating this solution into a comparison function is trivial: We decree that an object of one type is always less than an object of the other type, and continue to use the comparisons that we have already defined within each type. Another way to look at this solution is that each object becomes a string of two symbols, where the first one is the object's type, and we define ordering as dictionary ordering over these two-symbol strings.

The more general kind of "shuffling" is harder to define, because we need to be able to compare objects of different types while ensuring that the results of such comparisons are always consistent with each other. However, using dictionary order suggests one way of doing it: We find a string — such as a serial number — that describes each object, and then create a pair in which the first component is that string and the second component represents the type.

This strategy suggests a general technique: Represent each object's contents with a canonical value — a value of a single, well-defined type that already has an order relation defined on it. Then use the canonical values for comparison, perhaps appending the object's type if we want two objects of different types with the same canonical value to be ordered rather than conceptually equivalent.