Effective C++, 2E | Item 19: Differentiate among member functions, non-member functions, and friend functions Back to Item 18: Strive for class interfaces that are complete and minimal.
Continue to Item 20: Avoid data members in the public interface.
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;      // 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 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,     // this ctor is
int denominator = 1);  // now explicit
...

const Rational operator*(const Rational& rhs) const;

...

};


neither of these statements would compile: result = oneHalf * 2;             // error!
result = 2 * oneHalf;             // 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;           // 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 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. Back to Item 18: Strive for class interfaces that are complete and minimal.
Continue to Item 20: Avoid data members in the public interface.