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

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 (a.() + b.());
}

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 ;

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:

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;
    }

:
     meters;
};

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:

Member vs non-member operators

+ vs +=

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,  T& right);
 ==( T& a,  T& b);
 !=( T& a,  T& b);
std::ostream& <<(std::ostream& os,  T& value);
std::istream& >>(std::istream& is, T& value);

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.

• 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.