Why should I overload a C++ operator as a global function (STL does) and what are the caveats?

Question

Why would I want to overload a C++ operator() as global and not member function. For example, the == operator.

Why is this done? for example in STL libraries.

Answer 1

The usual rule is for operators which modify the left hand object to be members, and binary operators which return a new object to be free functions; the main motivation for the latter is because the compiler will not convert the left hand side to match a member; if your class supports any implicit conversions, then all of the usual binary operators should be free functions, so that the same rules of conversion apply
for the left hand side and the right hand side, e.g.:

class Complex
{
public:
    Complex(double r, double i = 0.0);
    bool operator==( Complex const& other ) const;
};

Complex a;
//  ...
if ( a == 1.0 ) // OK
//  ...
if ( 1.0 == a ) // error.

but:

class Complex
{
public:
    Complex(double r, double i = 0.0);
    friend bool operator==( Complex const& lhs, Complex const& rhs ) const;
};

Complex a;
//  ...
if ( a == 1.0 ) // OK
//  ...
if ( 1.0 == a ) // OK

One elegant way of achieving this is to define the basic operations in terms of member functions—for things like + or -, these would be operator+= and operator-=; for comparison, you'd need to define an arbitrary conventions, a member isEqual, or compare (which would return <, == or > zero according to the results, then inherit from a template along the lines of:

template <typename T>
class ArithmeticOperators
{
    friend T operator+( T const& lhs, T const& rhs )
    {
        T result( lhs );
        result += rhs;
        return result;
    }
    //  And so on, for all of the binary operators.
};

class Complex : public ArithmeticOperators<Complex>
{
public:
    //  ...
    Complex& operator+=( Complex const& other );
    //  etc.
};

Note that there is some argument for making the operator <op>= functions free functions as well: the fact that the free function will take a non-const reference as its first argument, and thus requires an lvalue (like the built-in operator <op>=). This doesn't seem to be the usual practice, however, probably because operator= must be a member, and it seems more natural to treat the operator <op>= in the same mannter.

Answer 2

If I remember correctly, operator = must be a member function. Regarding operator ==, I figure you don't actually mean global but free function instead (STL does not define operators globally). There are a couple of things to consider, one is decoupling from the class itself: If your operator can be defined in terms of the public interface of your class, then you are better off implementing it that way to keep the access to the implementation internals to the bare minimum. The other fundamental advantage is the possibility to implemement an operator where your type comes as the second operand, consider equality between types T and U:

bool operator ==( T const& t, U const& u ){ ... }
bool operator ==( U const& t, T const& u ){ ... }

If objects of type T and U can be equally compared, then it makes sense that both t == u and u == t are valid and both yield the same result. If you were defining this operator as a member function, then one would be within the implementation of T and the other within the implementation of U. Now consider U is a 3rd party type outside your control, or even better is a fundamental type such as int, now there is no other way for you to provide such operator but to provide the free function version of it.