Operator overloading

related topics
{math, number, function}
{work, book, publish}
{theory, work, human}

In computer programming, operator overloading (less commonly known as operator ad-hoc polymorphism) is a specific case of polymorphism in which some or all of operators like +, =, or == have different implementations depending on the types of their arguments. Sometimes the overloadings are defined by the language; sometimes the programmer can implement support for new types.

Operator overloading is claimed to be useful because it allows the developer to program using notation "closer to the target domain"[1] and allows user-defined types a similar level of syntactic support as types built into the language. It can easily be emulated using function calls; for an example, consider the integers a, b, c:

a + b * c

In a language that supports operator overloading, and assuming the '*' operator has higher precedence than '+', this is effectively a more concise way of writing:

add (a, multiply (b,c))

Contents

[edit] Examples

In this case, the addition operator is overloaded to allow addition on a user-defined type "Time" (in C++):

 Time operator+(const Time& lhs, const Time& rhs) {
     Time temp = lhs;
     temp.seconds += rhs.seconds;
     if (temp.seconds >= 60) {
         temp.seconds -= 60;
         temp.minutes++;
         }
     temp.minutes += rhs.minutes;
     if (temp.minutes >= 60) {
         temp.minutes -= 60;
         temp.hours++;
         }
     temp.hours += rhs.hours;
     return temp;
     }

Addition is a binary operation, which means it has left and right operands. In C++, the arguments being passed are the operands, and the temp object is the returned value.

The operation could also be defined as a class method, replacing lhs by the hidden this argument; however this forces the left operand to be of type Time and supposes this to be a potentially modifiable lvalue:

 Time Time::operator+(const Time& rhs) const {
     Time temp = *this;  /* Copy 'this' which is not to be modified */
     temp.seconds += rhs.seconds;
     if (temp.seconds >= 60) {
         temp.seconds -= 60;
         temp.minutes++;
         }
     temp.minutes += rhs.minutes;
     if (temp.minutes >= 60) {
         temp.minutes -= 60;
         temp.hours++;
         }
     temp.hours += rhs.hours;
     return temp;
     }

Note that a unary operator defined as a class method would receive no apparent argument (it only works from this):

 bool Time::operator!() const {
     return ((hours == 0) && (minutes == 0) && (seconds == 0));
     }

[edit] Criticisms

Operator overloading has often been criticized because it allows programmers to give operators completely different semantics depending on the types of their operands. For example the use of the << in C++'s:

a << 1

shifts the bits in the variable a left by 1 bit if a is of an integer type, but if a is an output stream then the above code will attempt to write a "1" to the stream. Because operator overloading allows the original programmer to change the usual semantics of an operator and to catch any subsequent programmers by surprise, it is usually considered good practice to use operator overloading with care.

The common reply to this criticism is that the same argument applies to function overloading as well. Furthermore, even in the absence of overloading, a programmer can define a function to do something totally different from what would be expected from its name. An issue that remains is that languages such as C++ provide a limited set of operator symbols, thus removing from programmers the option of choosing a more suitable operator symbol for their new operation.

Another, more subtle issue with operators is that certain rules from mathematics can be wrongly expected or unintentionally assumed. For example the commutativity of + (i.e. that a + b == b + a) does not always apply; an example of this occurs when the operands are strings, since + is commonly overloaded to perform a concatenation of strings (i.e. "school" + "bag" yields "schoolbag", which is different from "bag" + "school" yields "bagschool"). A typical counter to this argument comes directly from mathematics: While + is commutative on integers (and in general any real numbers), it is not commutative for other "types" of variable[citation needed]. It can be further noted that + is not even associative on floating point values in practice due to rounding errors. Another example: binary * (multiplication) is commutative for integers but not commutative in case of matrix multiplication.

[edit] Catalog

A classification of some common programming languages by whether their operators are overloadable by the programmer and whether the operators are limited to a predefined set.

Operators Not overloadable Overloadable
New definable
Limited set

[edit] Timeline of operator overloading

[edit] 1960s

The ALGOL 68 specification allowed operator overloading[6].

Full article ▸

related documents
Quasigroup
Cotangent space
Column space
Monotone convergence theorem
Special linear group
Borel algebra
Automata theory
Golden ratio base
Graftal
Least common multiple
Generating trigonometric tables
Associative algebra
Theory of computation
Product topology
Spectrum of a ring
Stirling's approximation
1 (number)
Sylow theorems
Measure (mathematics)
Jacobi symbol
Mean value theorem
De Morgan's laws
Free variables and bound variables
Diophantine equation
Discriminant
Cumulative distribution function
Cauchy-Riemann equations
Perfect number
NaN
Chain complex