22. Operator Overloading

Advanced perspective: familiar syntax borrows expectations from the language

An operator overload is successful only when its compact spelling tells the truth

Operator overloading lets a user-defined type participate in familiar C++ expressions. It does not let the type redesign the grammar. Precedence, associativity and the number of operands are fixed, new operator symbols cannot be invented, and at least one operand must involve a user-defined type. The compiler checks whether an overload is legal and selectable. It does not decide whether left + right has an honest meaning in the domain.

The compact syntax therefore carries a debt. A reader expects + to produce a value without unexpectedly modifying its operands, += to modify its left operand, == to express a coherent equality relation, and stream extraction to report failure without leaving a half-read object. If the type needs a paragraph of exceptions every time an operator appears, a named function may be the clearer interface.

Implement the mutating rule once, then derive the value operation

#include <iostream>

class Time {
public:
    explicit Time(int minutes) : minutes_{minutes} {}

    Time& operator+=(const Time& other) {
        minutes_ += other.minutes_;
        return *this;
    }

    int minutes() const {
        return minutes_;
    }

    friend Time operator+(Time left, const Time& right) {
        left += right;
        return left;
    }

private:
    int minutes_;
};

int main() {
    const Time first{40};
    const Time second{35};
    const Time total{first + second};
    std::cout << total.minutes() << '\n';
}

operator+= modifies its left object and returns that same object by reference. The return supports conventional expressions such as (a += b) += c without creating a replacement Time. The operation's one state rule is visible in one place.

operator+ is a non-member friend whose left operand is taken by value. That parameter is a copy of first. The function applies the established compound operation to the copy and returns the resulting value. Consequently, first remains 40, second remains 35, and total receives 75. The implementation relationship mirrors the semantic relationship: addition behaves like a non-mutating value form of compound addition.

The pattern is useful where += and + genuinely share one rule. It is not a quota that every type must satisfy. If the compound operation has different validity or performance requirements, state those differences rather than forcing code reuse to dictate semantics.

Decide what the type represents before deciding what the symbol means

The name Time is deliberately ambiguous. If it represents a duration measured in minutes, adding two values can make sense and 75 is a straightforward result. If it represents a time of day, adding two clock readings is not an obvious operation. A time of day plus a duration may be meaningful, perhaps with wraparound or a date transition, but that is a different type relationship.

This distinction changes the interface. One undifferentiated Time + Time overload can hide whether the operands are durations, points on a timeline or clock readings. Stronger domain types can prevent nonsense before an operator body runs. Syntax should follow the model. It should not be used to avoid choosing one.

Member, non-member and friend answer separate questions

Some operators must be members, including assignment, subscript, function call and member access through ->. For a symmetric binary operation such as value addition or equality, a non-member often treats both operands more evenly and allows relevant implicit conversions to be considered on either side. A member binary operator fixes the left operand as the object on which the member is invoked.

Non-member does not automatically mean friend. If public operations can implement the operator without weakening clarity or efficiency, an ordinary non-member preserves representation independence. Friendship is justified only when the non-member relationship is right and narrow private access is genuinely necessary. These are two decisions, not one combined slogan.

Equality and ordering must describe the domain, not merely the member list

A useful equality relation is expected to be reflexive, symmetric and transitive. If a == b, code commonly expects them to be interchangeable for the observations that define value identity. Approximate floating-point comparison can be useful for a named numerical test, but embedding a context-dependent tolerance in operator== can break transitivity and make containers or algorithms behave unexpectedly.

Defaulted equality and three-way comparison can remove repetitive member-wise code when member order and comparison already express the intended value semantics. They compare the relevant subobjects in their language-defined order and may be unavailable when those subobjects cannot supply the required comparisons. They do not decide whether a cache, identifier, timestamp or spelling variation belongs to value identity.

Input should commit only after the representation is complete

A stream insertion operator conventionally returns the stream by reference, allowing chained output and preserving the stream's accumulated state. It may be an ordinary non-member using public observations or a hidden friend when narrow representation access is justified.

Extraction is more dangerous because it mutates. Read components and delimiter characters into local temporary values, validate the entire representation, and assign to the target only after success. If the second coordinate or closing delimiter is absent, the stream should report failure and the object should retain its previous invariant-satisfying value. Directly extracting into members can leave the first member changed before a later read fails.

This is a transaction in miniature: parse, validate, then commit. The same pattern applies beyond streams whenever one logical update depends on several fallible steps.

Legal syntax can still remove behaviour readers depend upon

The operators ., .*, :: and ?: cannot be overloaded. Other operators are overloadable but lose special built-in behaviour. User-defined && and || do not provide the built-in short-circuit guarantee; both operands participate in the function-call evaluation needed for the overload. Code that expects the right operand to be skipped can therefore become invalid or expensive.

Overloading the comma operator, address-of or other low-level-looking syntax may likewise make ordinary reading unreliable. A domain can occasionally justify unusual notation, especially in a carefully constrained library. The burden of proof is high because the operator's spelling already tells experienced readers a story.

Conversions alter overload selection before the chosen function begins

A single-argument constructor or conversion operator can make additional overloads viable. That convenience can also make an unrelated expression compile by silently creating a temporary domain value. Mark conversions explicit when automatic conversion would hide cost, lose information or make operator selection surprising.

An explicit operator bool can still participate in the language's contextual Boolean uses, such as an if condition, while resisting broad arithmetic conversion. The decision is not "explicit is always safer". The decision is which implicit interpretations belong to the type's contract and which should require visible intent.

Transfer task: decide whether the symbol deserves the behaviour

Design a Percentage type whose valid values lie from 0 to 100. A proposal defines a + b as a saturating sum capped at 100, a += b with the same rule, approximate equality within one percentage point, and implicit conversion to int. For each choice, list the expectation a reader brings from the operator and the place where the proposal meets or breaks it.

Produce two designs. One may retain operators, but it must state the invariant, mutation rules, equality relation and conversion policy precisely. The other should replace misleading syntax with names such as capped_add or is_within. Add a stream extraction plan that leaves the target unchanged for 101, missing digits or trailing invalid syntax. Choose between the designs by clarity of the resulting call sites, not by which one demonstrates more overloads.

#include <algorithm>
#include <stdexcept>

class Percentage {
public:
    explicit Percentage(int value) : value_{value}
    {
        if (value < 0 || value > 100) {
            throw std::out_of_range{"percentage must be in [0, 100]"};
        }
    }

    Percentage& operator+=(Percentage other) noexcept
    {
        value_ = std::min(100, value_ + other.value_);
        return *this;
    }

    [[nodiscard]] int value() const noexcept { return value_; }
    explicit operator int() const noexcept { return value_; }

    bool operator==(const Percentage&) const = default;

private:
    int value_ = 0;
};

Percentage operator+(Percentage left, Percentage right) noexcept
{
    left += right;
    return left;
}

const Percentage combined = capped_add(tax, surcharge);

if (is_within(measured, expected, 1)) {
    // close enough for this particular decision
}

#include <charconv>
#include <ios>
#include <istream>
#include <string>
#include <system_error>

std::istream& operator>>(std::istream& in, Percentage& target)
{
    std::string token;
    if (!(in >> token)) {
        return in;
    }

    if (token.ends_with('%')) {
        token.pop_back();
    }

    int candidate = 0;
    const char* first = token.data();
    const char* last = first + token.size();
    const auto [next, error] = std::from_chars(first, last, candidate);

    if (token.empty()
        || token.find_first_not_of("0123456789") != std::string::npos
        || error != std::errc{}
        || next != last
        || candidate < 0
        || candidate > 100) {
        in.setstate(std::ios::failbit);
        return in;
    }

    target = Percentage{candidate};
    return in;
}

An operator overload succeeds when a reader can transfer ordinary C++ expectations to the user-defined type and remain correct. Compact syntax is valuable after the semantics are settled. Before that, it merely makes uncertainty shorter.