14.3.2. Relational Operators

Classes for which the equality operator is defined also often (but not always) have relational operators. In particular, because the associative containers and some of the algorithms use the less-than operator, it can be useful to define an operator<.

Ordinarily the relational operators should

1. Define an ordering relation that is consistent with the requirements for use as a key to an associative container (§ 11.2.2, p. 424); and

2. Define a relation that is consistent with == if the class has both operators. In particular, if two objects are !=, then one object should be < the other.

Although we might think our Sales_data class should support the relational operators, it turns out that it probably should not do so. The reasons are subtle and are worth understanding.

We might think that we’d define < similarly to compareIsbn (§ 11.2.2, p. 425). That function compared Sales_data objects by comparing their ISBNs. Although compareIsbn provides an ordering relation that meets requirment 1, that function yields results that are inconsistent with our definition of ==. As a result, it does not meet requirement 2.

The Sales_data == operator treats two transactions with the same ISBN as unequal if they have different revenue or units_sold members. If we defined the < operator to compare only the ISBN member, then two objects with the same ISBN but different units_sold or revenue would compare as unequal, but neither object would be less than the other. Ordinarily, if we have two objects, neither of which is less than the other, then we expect that those objects are equal.

We might think that we should, therefore, define operator< to compare each data element in turn. We could define operator< to compare objects with equal isbns by looking next at the units_sold and then at the revenue members.

However, there is nothing essential about this ordering. Depending on how we plan to use the class, we might want to define the order based first on either revenue or units_sold. We might want those objects with fewer units_sold to be “less than” those with more. Or we might want to consider those with smaller revenue “less than” those with more.

For Sales_data, there is no single logical definition of <. Thus, it is better for this class not to define < at all.