Basic Rules and Idioms for Operator Overloading in C++

By the end of this page, you will understand what operator overloading is, when it improves a C++ type, and the rules that make overloaded operators behave predictably. You will also see common signatures, examples, typical design patterns, and mistakes to avoid when building user-defined types.

Operator overloading in C++ lets you define how built-in operators such as +, ==, [], <<, or () behave for your own types.

For example, if you create a Vector2 class, writing a + b is often clearer than writing a.add(b). Operator overloading makes user-defined types feel natural to use.

However, operator overloading should match the meaning people already expect from the operator. That is the core rule.

Why it matters

Good operator overloading can make code:

• easier to read
• more expressive
• closer to mathematical or domain concepts
• easier to integrate with the standard library

Bad operator overloading can make code:

• surprising
• hard to debug
• inconsistent with normal C++ behavior

The basic idea

An overloaded operator is just a function with a special name such as:

operator+
operator==
operator[]

You can define operators as:

• member functions
• non-member functions
• sometimes friend functions when access to private data is needed

Important limits

C++ lets you overload many operators, but not all of them.

You cannot create new operators, and you cannot change:

• the number of operands
• operator precedence
• associativity
• the behavior of operators on built-in types

For example, overloading + for your class does not change how int + int works.

Three practical rules

1. Only overload operators that make sense

If your type has a natural "add", compare, index, call, or stream meaning, operator overloading may help. If not, use a normal named function.

2. Preserve expected semantics

If a + b modifies a, that is surprising. Usually:

• + returns a new value
• += modifies the left side
• == checks equality
• [] accesses an element

3. Keep related operators consistent

If you overload:

• ==, think about !=
• <, think about ordering as a whole
• +, consider +=
• *, consider *=

Consistency makes your type easier to learn and safer to use.

Think of operator overloading as teaching C++ how your object should behave in familiar situations.

A built-in type like int already knows what +, -, ==, and << mean. Your class does not. Operator overloading is like giving your class a set of behavior rules so it can participate in those same expressions.

A good analogy is a tool with standard controls:

• a power button should turn something on or off
• a volume knob should change loudness
• a play button should start playback

If someone made the play button delete files, that would be confusing.

Operators work the same way:

• + should feel like combining values
• == should feel like checking equality
• [] should feel like indexing
• () should feel like calling or applying

Use operators when they match user expectations. If the meaning is unusual, a named method is usually better.

General syntax

Member operator

A member operator uses the left-hand operand as *this.

class Counter {
public:
    Counter(int value = 0) : value(value) {}

    Counter operator+(const Counter& other) const {
        return Counter(value + other.value);
    }

private:
    int value;
};

Non-member operator

A non-member operator takes both operands as parameters.

class Counter {
public:
    Counter(int value = 0) : value(value) {}

    int get() const { return value; }

private:
    int value;
};

Counter operator+(const Counter& a, const Counter& b) {
    return Counter(a.get() + b.get());
}

A common idiom: implement + using +=

This avoids duplicated logic.

class Counter {
public:
    Counter(int value = 0) : value(value) {}

    Counter& operator+=(const Counter& other) {
        value += other.value;
        return *this;
    }

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

    int get() const { return value; }

private:
    int value;
};

Why this is good

• += performs the real mutation
• + works by copying the left operand, modifying the copy, and returning it
• behavior matches how built-in types work

Stream insertion example

<< for output is usually a non-member function.

#include <iostream>

class Counter {
public:
    Counter(int value = 0) : value(value) {}

    friend std::ostream& operator<<(std::ostream& os, const Counter& c) {
        os << c.value;
        return os;
    }

private:
    int value;
};

This allows:

Counter c(42);
std::cout << c << '\n';

Subscript operator example

#include <stdexcept>

class IntArray {
public:
    IntArray() : data{10, 20, 30} {}

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

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

private:
    int data[3];
};

Providing both const and non-const versions is a common idiom.

Comparison operator example

class Point {
public:
    Point(int x, int y) : x(x), y(y) {}

    friend bool operator==(const Point& a, const Point& b) {
        return a.x == b.x && a.y == b.y;
    }

    friend bool operator!=(const Point& a, const Point& b) {
        return !(a == b);
    }

private:
    int x;
    int y;
};

Member vs non-member guideline

Use a member when the operator must act on the object itself in a special way, especially for:

• =
• []
• ()
• ->
• +=, -=, *=, and other compound assignments

Use a non-member when symmetry matters, especially for binary operators like:

• +
• -
• *
• /
• ==
• <
• <<

This is especially useful when implicit conversions should work on both sides.

Consider this class:

class Counter {
public:
    Counter(int value = 0) : value(value) {}

    Counter& operator+=(const Counter& other) {
        value += other.value;
        return *this;
    }

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

    int get() const { return value; }

private:
    int value;
};

And this code:

Counter a(10);
Counter b(5);
Counter c = a + b;

What happens step by step

1. a is created

Counter a(10);

• a.value becomes 10

2. b is created

Counter b(5);

• b.value becomes 5

3. a + b calls operator+

Counter c = a + b;

This calls:

operator+(a, b)

But the first parameter is passed by value:

friend Counter operator+(Counter left, const Counter& right)

So:

• left becomes a copy of a
• left.value is initially 10
• right refers to b

4. left += right runs

Inside operator+:

left += right;

This calls:

left.operator+=(right)

Inside operator+=:

value += other.value;

So:

• left.value = 10 + 5
• left.value becomes 15

5. left is returned

return left;

The result is a new Counter with value 15.

6. c receives the result

• c.value becomes 15
• a is still 10
• b is still 5

Final state

• a.get() is 10
• b.get() is 5
• c.get() is 15

This is the expected behavior for +: it creates a new result instead of modifying the original left operand.

Operator overloading is common when a type has a clear, natural set of operations.

Mathematical types

Examples:

• Vector2, Vector3, matrices
• complex numbers
• fractions or big integers

Useful operators:

• +, -, *, /
• +=, -=, *=
• ==

Container-like types

Examples:

• custom array wrappers
• matrix row access
• string-like classes

Useful operators:

• [] for element access
• == for equality
• <=> or ordering operators when needed

Smart pointer or handle types

Examples:

• resource wrappers
• pointer-like proxy objects

Useful operators:

• * for dereference
• -> for member access
• bool conversion for validity checks

Stream-friendly domain objects

Examples:

• logging structures
• config values
• debug output for custom types

Useful operators:

• << for output
• >> for parsing input

Function-like objects

Examples:

• predicates
• comparators
• callbacks
• transformation objects

Useful operator:

• () for callable behavior

This is heavily used in the standard library and generic programming.

In real projects, operator overloading is usually kept small, predictable, and aligned with standard conventions.

Common patterns

Implement compound assignment first

Developers often write:

• operator+=
• operator-=
• operator*=

Then derive the non-mutating versions:

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

This reduces duplication.

Use non-member operators for symmetry

For binary operators, non-members often allow conversions on both operands.

class Distance {
public:
    Distance(double meters) : meters(meters) {}

    Distance& operator+=(const Distance& other) {
        meters += other.meters;
        return *this;
    }

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

private:
    double meters;
};

Provide const and non-const accessors

For operator[], real code often provides both versions:

T& operator[](std::size_t i);
const T& operator[](std::size_t i) const;

Use guard-style checks in stream extraction or indexing

For parsing or validation:

• fail the stream if input is invalid
• throw or assert if indexing is out of range, depending on the type design

Keep conversions explicit when needed

Conversion operators can be dangerous if used too freely.

Modern C++ often prefers:

explicit operator bool() const;

This allows safe truth testing while preventing accidental numeric conversions.

Support comparisons carefully

In modern C++, developers often prefer defaulted comparisons when appropriate:

class Point {
public:
    int x;
    int y;

    auto operator<=>(const Point&) const = default;
};

This can generate comparison behavior automatically when the type's members support it.

1. Giving an operator a surprising meaning

Bad idea:

class File {
public:
    void operator+(const File&) {
        // deletes the file
    }
};

Why it is wrong:

• + is expected to combine values, not trigger unrelated side effects

Use a named function instead.

2. Making + modify the left operand

Broken example:

class Counter {
public:
    Counter(int value) : value(value) {}

    Counter& operator+(const Counter& other) {
        value += other.value;
        return *this;
    }

private:
    int value;
};

Problem:

• users expect + to return a new value
• mutation belongs in +=

Better:

Counter& operator+=(const Counter& other);
friend Counter operator+(Counter left, const Counter& right);

3. Returning the wrong type from assignment

Broken example:

class X {
public:
    void operator=(const X& other) {
        value = other.value;
    }
private:
    int value;
};

Why it is wrong:

• assignment should usually return X&
• this supports chaining like a = b = c

Correct form:

X& operator=(const X& other) {
    value = other.value;
    return *this;
}

4. Forgetting const correctness

Broken example:

bool operator==(const Point& other) {
    return x == other.x && y == other.y;
}

Problem:

• cannot compare const objects cleanly

Better:

bool operator==(const Point& other) const {
    return x == other.x && y == other.y;
}

5. Overloading && and || expecting short-circuit behavior

This is a common trap.

Even if overloaded, they behave like function calls and do not preserve built-in short-circuit semantics in the same way developers usually expect.

Most classes should avoid overloading them.

6. Choosing member functions when symmetry is needed

If operator+ is a member, implicit conversion only applies naturally to the right-hand side.

That can lead to awkward behavior.

Non-member forms are often better for symmetric binary operators.

7. Returning by value when a reference is needed

For indexing:

int operator[](std::size_t i) { return data[i]; }

This prevents assignment through the operator:

arr[0] = 10; // fails if operator[] returns by value

Better:

int& operator[](std::size_t i) { return data[i]; }

8. Overloading too many operators

Just because an operator can be overloaded does not mean it should be. Prefer clarity over cleverness.

Member vs non-member operators

+ vs +=

== vs <=>

[] vs .at() style access

Conversion operator vs named conversion method

Core rules

• Overload operators only when the meaning is natural.
• Preserve expected semantics.
• Keep related operators consistent.
• Prefer clarity over cleverness.

What you cannot change

• precedence
• associativity
• number of operands
• behavior of operators on built-in types
• you cannot invent new operators

Common member operators

T& operator=(const T& other);
T& operator+=(const T& other);
T& operator-=(const T& other);
T& operator*=(const T& other);
T& operator/=(const T& other);
T& operator[](std::size_t index);
const T& operator[](std::size_t index) const;
R operator()(...);
U* operator->();
const U* operator->() const;

Common non-member operators

T operator+(T left, const T& right);
T operator-(T left, const T& right);
bool operator==(const T& a, const T& b);
bool operator!=(const T& a, const T& b);
std::ostream& operator<<(std::ostream& os, const T& value);
std::istream& operator>>(std::istream& is, T& value);

Common idiom for binary arithmetic

class T {
public:
    T& operator+=(const T& other) {
        // modify *this
        return *this;
    }

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

Assignment rule

T& operator=(const T& other);

Usually return *this.

Stream rule

friend std::ostream& operator<<(std::ostream& os, const T& value);
friend std::istream& operator>>(std::istream& is, T& value);

Always return the stream.

Comparison rule

bool operator==(const T& other) const;

Or use a non-member/friend form.

Useful modern conversion form

explicit operator bool() const;

Be careful with

• && and ||
• ,
• unusual conversion operators
• surprising meanings
• returning by value instead of reference for []

When should I overload an operator in C++?

Overload an operator when your type has a clear, natural meaning for it and users will reasonably expect that syntax.

Should operator+ be a member or non-member?

Usually non-member. It gives better symmetry and works better with implicit conversions on both operands.

Why is operator+= often implemented before operator+?

Because += contains the core mutation logic. Then + can reuse it by copying the left operand and returning the modified copy.

Does overloading an operator change it for built-in types?

No. It only affects expressions involving your user-defined type.

Can I overload every operator in C++?

No. Some operators cannot be overloaded, and you also cannot create brand new operators.

Should stream operators be member functions?

Usually no. operator<< and operator>> are typically non-member functions, often declared as friend if they need private access.

Is overloading && or || a good idea?

Usually not. Their overloaded behavior does not match the short-circuit expectations people have from built-in logical operators.

What is the safest conversion operator to provide?

A common safe choice is explicit operator bool() const, which allows truth testing without opening the door to many accidental conversions.

• Const correctness — important for comparison, indexing, and read-only operator overloads.
• Copy constructor and copy assignment — closely related to implementing value-like types correctly.
• Move semantics — useful when overloaded operators return or transfer objects efficiently.
• Friend functions — often used for non-member operators that need private access.
• Implicit and explicit conversions — directly related to conversion operators and overload resolution.
• RAII — essential when overloading operators for resource-managing types.
• Three-way comparison (<=>) — modern C++ feature for defining ordering consistently.
• Function objects — related to overloading operator().
• Smart pointers — common examples of overloading *, ->, and bool conversion.
• Stream I/O — related to overloading << and >> for custom types.