Item 19: Differentiate among member functions, non-member functions, and friend functions.

Item 19: Differentiate among member functions, non-member functions, and friend functions.
The biggest difference between member functions and non-member functions is that member functions can be
virtual and non-member functions can't. As a result, if you have a function that has to be dynamically bound (see
Item 38), you've got to use a virtual function, and that virtual function must be a member of some class. It's as
simple as that. If your function doesn't need to be virtual, however, the water begins to muddy a bit.
Consider a class for representing rational numbers:
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
int numerator() const;
int denominator() const;
private:
...
};
As it stands now, this is a pretty useless class. (Using the terms of Item 18, the interface is certainly minimal,
but it's far from complete.) You know you'd like to support arithmetic operations like addition, subtraction,
multiplication, etc., but you're unsure whether you should implement them via a member function, a non-member
function, or possibly a non-member function that's a friend.
When in doubt, be object-oriented. You know that, say, multiplication of rational numbers is related to the
Rational class, so try bundling the operation with the class by making it a member function:
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 by-value result, but taking a
reference-to-const as its argument ? consult Items 21-23.)
Now you can multiply rational numbers 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 mixed-mode operations, where Rationals can be multiplied
with, for example, ints. When you try to do this, however, you find that it works only half the time:
result = oneHalf * 2;
result = 2 * oneHalf;
// fine
// 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 your compilers call that function.
However, the integer 2 has no associated class, hence no operator* member function. Your compilers will also
look for a non-member operator* (i.e., one that's in a visible namespace or is global) that can be called like
this,
result = operator*(2, oneHalf);
// error!
but there is no non-member 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. Your compilers know you're passing an int and the function requires
a Rational, but they also know that they can conjure up a suitable Rational by calling the Rational constructor
with the int you provided, so that's what they do (see Item M19). In other words, 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, they do this only when non-explicit constructors are involved, because explicit constructors can't be
used for implicit conversions; that's what explicit means. If Rational were defined like this,
class Rational {
public:
explicit Rational(int numerator = 0,
int denominator = 1);
...
// this ctor is
// now explicit
const Rational operator*(const Rational& rhs) const;
...
};
neither of these statements would compile:
result = oneHalf * 2;
result = 2 * oneHalf;
// error!
// error!
That would hardly qualify as support for mixed-mode arithmetic, but at least the behavior of the two statements
would be consistent.
The Rational class we've been examining, however, is designed to allow implicit conversions from built-in
types to Rationals ? that's why Rational's constructor isn't declared explicit. That being the case, compilers will
perform the implicit conversion necessary to allow result's first assignment to compile. In fact, your
handy-dandy compilers will perform this kind of implicit type conversion, if it's needed, on every parameter of
every function call. But they will do it only for parameters listed in the parameter list, never for the object on
which a member function is invoked, i.e., the object corresponding to *this inside a member function. That's why
this call works,
result = oneHalf.operator*(2);
// converts int -> Rational
and this one does not:
result = 2.operator*(oneHalf);
// doesn't convert
// int -> Rational
The first case involves a parameter listed in the function declaration, but the second one does not.
Nonetheless, you'd still like to support mixed-mode arithmetic, and the way to do it is by now perhaps clear:
make operator* a non-member function, thus allowing compilers to perform implicit type conversions on all
arguments:
class Rational {
...
// contains no operator*
};
// declare this globally or within a namespace; see
// Item M20 for why it's written as it is
const Rational operator*(const Rational& lhs,
const Rational& rhs)
{
return Rational(lhs.numerator() * rhs.numerator(),
lhs.denominator() * rhs.denominator());
}
Rational oneFourth(1, 4);
Rational result;
result = oneFourth * 2;
result = 2 * oneFourth;
// fine
// 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 the class's public
interface. The code above shows one way to do it. Whenever you can avoid friend functions, you should,
because, much as in real life, friends are often more trouble than they're worth.
However, it's not uncommon for functions that are not members, yet are still conceptually part of a class
interface, to need access to the non-public members of the class.
As an example, let's fall back on a workhorse of this book, the String class. If you try to overload operator>>
and operator<< for reading and writing String objects, you'll quickly discover that they shouldn't be member
functions. If they were, you'd have to put the String object on the left when you called the functions:
// a class that incorrectly declares operator>> and
// operator<< as member functions
class String {
public:
String(const char *value);
...
istream& operator>>(istream& input);
ostream& operator<<(ostream& output);
private:
char *data;
};
String s;
s >> cin;
// legal, but contrary
// to convention
s << cout;
// ditto
That would confuse everyone. As a result, these functions shouldn't be member functions. Notice that this is a
different case from the one we discussed above. Here the goal is a natural calling syntax; earlier we were
concerned about implicit type conversions.
If you were designing these functions, you'd come up with something like this:
istream& operator>>(istream& input, String& string)
{
delete [] string.data;
read from input into some memory, and make string.data
point to it
return input;
}
ostream& operator<<(ostream& output,
const String& string)
{
return output << string.data;
}
Notice that both functions need access to the data field of the String class, a field that's private. However, you
already know that you have to make these functions non-members. You're boxed into a corner and have no
choice: non-member functions with a need for access to non-public members of a class must be made friends of
that class.
The lessons of this Item are summarized below, in which it is assumed that f is the function you're trying to
declare properly and C is the class to which it is conceptually related:
 Virtual functions must be members. If f needs to be virtual, make it a member function of C.
 operator>> and operator<< are never members. If f is operator>> or operator<<, make f a non-member
function. If, in addition, f needs access to non-public members of C, make f a friend of C.
 Only non-member functions get type conversions on their left-most argument. If f needs type
conversions on its left-most argument, make f a non-member function. If, in addition, f needs access to
non-public members of C, make f a friend of C.
 Everything else should be a member function. If none of the other cases apply, make f a member
function of C.