Operator overloading

What it is and why it exists

Operator overloading declares an operator function for an existing C++ operator. When at least one expression operand has class or enumeration type, the compiler may choose that function instead of a built-in operation. Expressions such as total + tax, version < candidate, and scores[index] can then state domain operations directly.

This is an interface feature. If a distance, amount, or complex number has value semantics , spelling addition as add(left, right) throws away the familiar structure of arithmetic. Iterators, smart handles, and function objects similarly use *, ->, or () to take part in generic interfaces.

Symbols don’t rescue a weak design. If the relationship between two operands has no accepted meaning, merge_with_policy() is usually clearer than a strained overload of |. Readers also expect + to produce a new value, += to change the left side, and == to agree with ordering; breaking those conventions needs an unusually good reason.

An overload can’t create a new symbol or alter precedence, grouping, or operand count. ., .*, ::, and ?: can’t be overloaded, while sizeof, typeid, and alignof aren’t operator-function names either. The language still controls syntax; the type author controls only the behavior after a function is selected.

You’ll meet overloaded operators in numeric classes, containers, iterators, smart pointers, stream output, comparisons, and callable objects. Assignment and resource ownership belong to special-member design, while the call operator belongs to function-object design. This topic explains how they enter the same operator machinery and leaves their full designs to the related topics.

How it works

You can roughly read left + right as left.operator+(right) or operator+(left, right), but the compiler doesn’t try those spellings in a fixed order. It builds candidate sets and runs overload resolution , comparing viability and conversion sequences before selecting one unique best function.

The sets can include member candidates, non-member candidates found through ordinary and argument-dependent lookup, built-in candidates, and the rewritten candidates used by C++20 comparisons. If no operand has class or enumeration type, only built-in operations are considered. Declaring operator+(int, int) can’t replace integer addition.

A member function treats the left operand as its implicit object. A non-member writes both operands as parameters, which usually fits a symmetric binary operation better. operator=, operator[], operator(), and operator-> must be members. To support std::cout << value, however, operator<< must be a non-member because you can’t add a member to the left-hand std::ostream type.

friend isn’t required for a non-member operator; it merely grants access to private members. A friend operator defined inside a class definition is still a non-member, usually found only through argument-dependent lookup (ADL) . This hidden friend keeps the operation beside its associated type without exposing another broadly visible name to ordinary unqualified lookup.

The member form affects conversion symmetry. For value + 2, a member value.operator+(2) can convert the right argument. But the left side of 2 + value isn’t an object of the class, so that same member doesn’t become callable. If a mixed operation should work both ways, provide the appropriate non-member overloads and decide whether converting constructors should be explicit; don’t rely on accidental conversions.

Common return types come from semantics, not a syntactic requirement:

Member operators that don’t change observable state should normally be const. Compound assignment can also be the single implementation source for binary arithmetic: copy the left value, then apply += to that copy. This keeps two addition implementations from drifting apart.

Examples

These four examples cover value operations, mixed operands, subscript references, and explicit conversion in that order. Every output below came from GCC 13.3 with -std=c++23, with address and undefined-behavior sanitizers enabled.

Building addition from compound assignment

Distance::operator+= changes the current object and returns a reference. The hidden operator+ takes its left-side copy by value and reuses +=, so + leaves the original route unchanged.

The constructor is explicit, so a bare integer doesn’t quietly become a Distance. Callers must name the unit type instead of accidentally treating seconds or another integer as metres. constexpr also lets the same arithmetic participate in constant evaluation when its inputs permit it.

The hidden friend could access metres_, but it still composes behavior through the public +=. If addition later needs an overflow check or invariant maintenance, there is one mutation path to update.

Supporting both operand orders deliberately

Scalar multiplication usually has a mathematical meaning in either order. Two non-member overloads put both amount * 2 and 2 * amount in the interface, with the second implementation delegating to the first.

#include <iostream>

class Money {
    long cents_;

public:
    explicit constexpr Money(long cents) : cents_(cents) {}

    friend constexpr Money operator*(Money amount, int multiplier) {
        return Money{amount.cents_ * multiplier};
    }

    friend constexpr Money operator*(int multiplier, Money amount) {
        return amount * multiplier;
    }

    friend std::ostream& operator<<(std::ostream& out, const Money& amount) {
        return out << amount.cents_ << " cents";
    }
};

int main() {
    const Money price{1299};

    std::cout << "price * 2: " << price * 2 << '\n';
    std::cout << "3 * price: " << 3 * price << '\n';
}

price * 2: 2598 cents
3 * price: 3897 cents

This interface doesn’t accept double and pretend rounding is solved. A production money type also needs policies for overflow, currency, and decimal scale. Adding more overloads before those rules exist only makes an ambiguous interface larger.

Both functions take Money by value, which is cheap for this one-integer type. For a larger type, a common design takes the left object to be modified by value, accepts the other operand by const&, and reuses *=.

Providing writable and read-only subscripts

The non-const subscript returns int&, so scores[0] = 10 changes an element. Its const overload returns const int&, letting read-only callers use the same syntax without gaining a path to mutate the object.

#include <array>
#include <cstddef>
#include <iostream>

class Scores {
    std::array<int, 3> values_;

public:
    explicit Scores(std::array<int, 3> values) : values_(values) {}

    int& operator[](std::size_t index) {
        return values_[index];
    }

    const int& operator[](std::size_t index) const {
        return values_[index];
    }
};

void print_first(const Scores& scores) {
    std::cout << "first score: " << scores[0] << '\n';
}

int main() {
    Scores scores{{7, 8, 9}};
    print_first(scores);
    scores[0] = 10;
    print_first(scores);
}

first score: 7
first score: 10

This operator[] follows the unchecked contract of std::array::operator[]; an out-of-range index has undefined behavior. If a type promises bounds checking, check and throw in the operator or provide a separate at() like standard containers do. The name and documentation must tell callers which contract they get.

A value-returning subscript can make reads appear correct while preventing assignment. Supplying only the non-const overload instead makes an ordinary reader taking const Scores& fail to compile. Both omissions are common when generated code is exercised through only one call site.

Keeping boolean conversion explicit

explicit operator bool() permits the object in if and other boolean contexts while keeping it out of accidental integer arithmetic. The stream operator returns the stream it received, so later output can remain in the same chain.

#include <iostream>
#include <string_view>

class Subscription {
    std::string_view name_;
    bool active_;

public:
    Subscription(std::string_view name, bool active) : name_(name), active_(active) {}

    explicit operator bool() const noexcept {
        return active_;
    }

    friend std::ostream& operator<<(std::ostream& out, const Subscription& plan) {
        return out << plan.name_;
    }
};

int main() {
    const Subscription pro{"pro", true};
    const Subscription trial{"trial", false};

    if (pro) {
        std::cout << pro << " can sync\n";
    }
    std::cout << trial << " can sync: " << std::boolalpha
              << static_cast<bool>(trial) << '\n';
}

pro can sync
trial can sync: false

A contextual conversion considers this explicit function, so if (pro) is valid. To store the result in a bool, the caller writes static_cast<bool>(trial). This shape works for an “engaged/empty” or “valid/invalid” state; it shouldn’t replace a named query when the object has several states.

The sample’s std::string_view doesn’t own its characters. Its names come from string literals here, so their lifetimes are long enough. If the constructor receives a temporary string, correct operator functions still can’t repair the dangling view; the type needs a separate ownership contract.

Pitfalls

Letting + mutate the left operand

Fix: let += perform mutation and return T&; let + work on a left-side copy and return it by value. After result = a + b, test that a and b kept their values. Also check that the address returned by a += b is &a.

Returning a dangling reference or the wrong category

Fix: return new values by value, current-object mutations by T&, and stream operations by std::ostream&. Don’t make a by-value result const; that adds no ownership guarantee and can interfere with later moves or overload selection.

Making a symmetric operation member-only

Fix: use non-members or hidden friends for genuinely symmetric binary operations, then compile both operand orders. Keep constructors explicit when a conversion could lose a unit, precision, or range, and declare only the mixed combinations the domain actually permits.

Defaulting comparisons over the wrong fields

Fix: list the fields that define equality and order before deciding to write = default. Test equal objects, objects differing only in cache state, boundary values, and NaN. If the type is used in ordered containers, verify that its comparison satisfies their strict-weak-order contract.

Expecting overloaded && or || to short-circuit

Fix: don’t use these overloads as control-flow guards. Prefer a named function, an ordinary if, or built-in boolean operators over explicit boolean queries. Test with a side effect on the right when evaluation behavior matters.

Filling the candidate set with implicit conversions

Fix: make converting constructors and conversion functions explicit by default, relaxing that only for conversions that are genuinely lossless and natural in the domain. Ask the compiler for the concrete candidates and keep compile-time tests for mixed-type expressions that should remain invalid.

Omitting constness or a bounds contract from subscripts

Fix: when container semantics call for it, provide matching reference-returning const and non-const overloads and choose checked or unchecked access explicitly. Compile writable, read-only, and out-of-range tests. If there is also an at(), verify that the two entry points really have different contracts.

Further reading

• C++23 draft: overloaded operators
• C++23 draft: operator candidates in expressions
• C++23 draft: defaulted comparison operators
• C++ Core Guidelines: operator overloading rules