I noted in the Introduction to this book that having classes support implicit type conversions is generally a bad idea. Of course, there are exceptions to this rule, and one of the most common is when creating numerical types. For example, if you're designing a class to represent rational numbers, allowing implicit conversions from integers to rationals doesn't seem unreasonable. It's certainly no less reasonable than C++'s builtin conversion from int to double (and it's a lot more reasonable than C++'s builtin conversion from double to int). That being the case, you might start your Rational class this way: class Rational { public: Rational(int numerator = 0, // ctor is deliberately not explicit; int denominator = 1); // allows implicit inttoRational // conversions int numerator() const; // accessors for numerator and int denominator() const; // denominator see Item 22 private: ... }; You know you'd like to support arithmetic operations like addition, multiplication, etc., but you're unsure whether you should implement them via member functions, nonmember functions, or, possibly, nonmember functions that are friends. Your instincts tell you that when you're in doubt, you should be objectoriented. You know that, say, multiplication of rational numbers is related to the Rational class, so it seems natural to implement operator* for rational numbers inside the Rational class. Counterintuitively, Item 23 argues that the idea of putting functions inside the class they are associated with is sometimes contrary to objectoriented principles, but let's set that aside and investigate the idea of making operator* a member function of Rational: class Rational { public: ... const Rational operator*(const Rational& rhs) const; }; (If you're unsure why this function is declared the way it is returning a const byvalue result, but taking a referencetoconst as its argument consult Items 3, 20, and 21.) This design lets you multiply rationals with the greatest of ease: Rational oneEighth(1, 8); Rational oneHalf(1, 2); Rational result = oneHalf * oneEighth; // fine result = result * oneEighth; // fine But you're not satisfied. You'd also like to support mixedmode operations, where Rationals can be multiplied with, for example, ints. After all, few things are as natural as multiplying two numbers together, even if they happen to be different types of numbers. When you try to do mixedmode arithmetic, however, you find that it works only half the time: result = oneHalf * 2; // fine result = 2 * oneHalf; // error! This is a bad omen. Multiplication is supposed to be commutative, remember? The source of the problem becomes apparent when you rewrite the last two examples in their equivalent functional form: result = oneHalf.operator*(2); // fine result = 2.operator*(oneHalf); // error! The object oneHalf is an instance of a class that contains an operator*, so compilers call that function. However, the integer 2 has no associated class, hence no operator* member function. Compilers will also look for nonmember operator*s (i.e., ones at namespace or global scope) that can be called like this: result = operator*(2, oneHalf); // error! But in this example, there is no nonmember operator* taking an int and a Rational, so the search fails. Look again at the call that succeeds. You'll see that its second parameter is the integer 2, yet Rational::operator* takes a Rational object as its argument. What's going on here? Why does 2 work in one position and not in the other? What's going on is implicit type conversion. Compilers know you're passing an int and that the function requires a Rational, but they also know they can conjure up a suitable Rational by calling the Rational constructor with the int you provided, so that's what they do. That is, they treat the call as if it had been written more or less like this: const Rational temp(2); // create a temporary // Rational object from 2 result = oneHalf * temp; // same as oneHalf.operator*(temp); Of course, compilers do this only because a nonexplicit constructor is involved. If Rational's constructor were explicit, neither of these statements would compile: result = oneHalf * 2; // error! (with explicit ctor); // can't convert 2 to Rational result = 2 * oneHalf; // same error, same problem That would fail to support mixedmode arithmetic, but at least the behavior of the two statements would be consistent. Your goal, however, is both consistency and support for mixedmode arithmetic, i.e., a design where both of the above statements will compile. That brings us back to these two statements and why, even when Rational's constructor is not explicit, one compiles and one does not: result = oneHalf * 2; // fine (with nonexplicit ctor) result = 2 * oneHalf; // error! (even with nonexplicit ctor) It turns out that parameters are eligible for implicit type conversion only if they are listed in the parameter list. The implicit parameter corresponding to the object on which the member function is invoked the one this points to is never eligible for implicit conversions. That's why the first call compiles and the second one does not. The first case involves a parameter listed in the parameter list, but the second one doesn't. You'd still like to support mixedmode arithmetic, however, and the way to do it is by now perhaps clear: make operator* a nonmember function, thus allowing compilers to perform implicit type conversions on all arguments: class Rational { ... // contains no operator* }; const Rational operator*(const Rational& lhs, // now a nonmember const Rational& rhs) // function { return Rational(lhs.numerator() * rhs.numerator(), lhs.denominator() * rhs.denominator()); } Rational oneFourth(1, 4); Rational result; result = oneFourth * 2; // fine result = 2 * oneFourth; // hooray, it works! This is certainly a happy ending to the tale, but there is a nagging worry. Should operator* be made a friend of the Rational class? In this case, the answer is no, because operator* can be implemented entirely in terms of Rational's public interface. The code above shows one way to do it. That leads to an important observation: the opposite of a member function is a nonmember function, not a friend function. Too many C++ programmers assume that if a function is related to a class and should not be a member (due, for example, to a need for type conversions on all arguments), it should be a friend. This example demonstrates that such reasoning is flawed. Whenever you can avoid friend functions, you should, because, much as in real life, friends are often more trouble than they're worth. Sometimes friendship is warranted, of course, but the fact remains that just because a function shouldn't be a member doesn't automatically mean it should be a friend. This Item contains the truth and nothing but the truth, but it's not the whole truth. When you cross the line from ObjectOriented C++ into Template C++ (see Item 1) and make Rational a class template instead of a class, there are new issues to consider, new ways to resolve them, and some surprising design implications. Such issues, resolutions, and implications are the topic of Item 46. Things to Remember
