Gotcha #84: Improper Operator Overloading

class Complex { 
 public:
   Complex( double real = 0.0, double imag = 0.0 );
   friend Complex add( const Complex &, const Complex & );
   friend Complex div( const Complex &, const Complex & );
   friend Complex mul( const Complex &, const Complex & );
   // . . .
};
// . . .
Z = add( add( R, mul( mul( j, omega ), L ) ),
   div( 1, mul( j, omega ), C ) ) );

Operator overloading is often just "syntactic sugar," but it makes reading and writing code more palatable and eases the communication of a design's meaning:

class Complex { 
 public:
   Complex( double real = 0.0, double imag = 0.0 );
   friend Complex operator +( const Complex &, const Complex & );
   friend Complex operator *( const Complex &, const Complex & );
   friend Complex operator /( const Complex &, const Complex & );
   // . . .
};
// . . .
Z = R + j*omega*L + 1/(j*omega*C);

The version of the formula for AC impedance using infix operators is correct, but the earlier version that employed function call syntax is not. However, the error is harder to see and correct without the use of operator overloading.

Operator overloading is also justified when extending an existing syntactic framework, like the iostream and standard template libraries:

ostream &operator <<( ostream &os, const Complex &c ) 
   { return os << '(' << c.r_ << ", " << c.i_ << ')'; }

These successful uses often encourage novice designers to overuse operator overloading:

template <typename T> 
class Stack {
 public:
   Stack();
   ~Stack();
   void operator +( const T & ); // push
   T &operator *(); // top
   void operator -(); // pop
   operator bool() const; // not empty?
   // . . .
};
// . . .
Stack<int> s;
s + 12;
s + 13;
if( s ) {
   int a = *s;
   -s;
   // . . .

Clever? No, it's puerile nonsense. Operator overloading exists largely to make code radically and universally clearer to its readers, not so the designer can show off. Use of an overloaded operator should appeal to readers' existing prejudices, so any reasonable assumption an experienced reader makes about an operator's meaning will be correct. A proper implementation of a stack would employ the universally recognized, non-operator names for the stack's operations:

template <typename T> 
class Stack {
 public:
   Stack();
   ~Stack();
   void push( const T & );
   T &top();
   void pop();
   bool isEmpty() const;
   // . . .
};
// . . .
Stack<int> s;
s.push( 12 );
s.push( 13 );
if( !s.isEmpty() ) {
   int a = s.top();
   s.pop();
   // . . .

Note that the meaning of an overloaded operator must be universally understood to be valid. Even if the meaning of an overloaded operator is obvious to you and 75% of your colleagues, a 25% rate of misunderstanding and misapplication is unacceptable, and overloading the operator will cause more problems than it solves.

A personal example brought this home to me. I was designing a simple array template:

gotcha05/array.h

template <class T, int n> 
class Array {
 public:
   Array();
   explicit Array( const T &val );
   Array &operator =( const T &val ); // universally obvious?
   // . . .
 private:
   T a_[n];
};
// . . .
Array<float,100> ary( 0 );
ary = 123; // obvious?

I was absolutely convinced that the effect of the assignment was obvious. Clearly, it means that I want to assign the value 123 to every element of the array. Right? Not according to significant percentages of users of the Array template. Some experienced programmers thought it meant to resize the array to have 123 elements. Some thought it meant to assign 123 to the first element. I knew I was right and that everyone who thought differently was wrong, but practicality forced me to back off and use an unambiguous non-operator function for that operation:

ary.setAll( 123 ); // boring, but clear 

Unless overloading an operator is clearly better than the alternative of a non-operator function, don't overload the operator.