C++ Operator Overloading: Custom +, ==, and << Operators

Making Your Types Feel Built-In

You already know that std::string lets you write a + b to concatenate and cout << s to print. Those aren't special compiler tricks - they're ordinary functions with funny names. Operator overloading is the feature that lets your classes plug into the same syntax, so a Vector2 or Money type can be added, compared, and printed exactly like an int.

The mechanism is simple once you see it: an expression like a + b is shorthand. The compiler rewrites it as a call to a function named operator+ and looks for one that matches the operand types. Define that function for your class and a + b suddenly works. This is really a specialized form of function overloading - the same name-resolution rules from there apply, just with operator-shaped names.

#include <iostream>
using namespace std;

struct Vector2 {
    double x, y;
};

// a + b becomes operator+(a, b)
Vector2 operator+(const Vector2& a, const Vector2& b) {
    return Vector2{a.x + b.x, a.y + b.y};
}

int main() {
    Vector2 p{1, 2};
    Vector2 q{3, 4};
    Vector2 r = p + q;          // calls operator+
    cout << r.x << ", " << r.y << "\n";  // 4, 6
}

Note the function takes both operands by const&: arithmetic shouldn't modify its inputs, and references avoid copying. It returns a new Vector2 by value - p + q must yield a fresh result without touching p or q, just like 2 + 3 doesn't change 2.

Member vs Non-Member

There are two places to define an operator: as a member of the class or as a free (non-member) function. As a member, the left operand is the implicit this, so a binary operator takes only one explicit parameter:

#include <iostream>
using namespace std;

class Money {
    long cents;
public:
    Money(long c) : cents(c) {}

    // member: left operand is *this, right operand is the parameter
    Money operator+(const Money& other) const {
        return Money(cents + other.cents);
    }

    long value() const { return cents; }
};

int main() {
    Money a(150), b(99);
    Money total = a + b;        // a.operator+(b)
    cout << total.value() << "\n";  // 249
}

The const after the parameter list matters: a + b shouldn't modify a, so the member is marked const. Use the member form for operators that are inherently tied to the left operand and don't need conversions on it - +=, [], (), ->, and unary operators like -x or ++x.

The catch with members: the left operand can't be converted. With the member operator+ above, a + 50 works (50 converts to Money for the right side), but 50 + a does not compile - the left operand 50 is an int, and you can't add a member function to int. A non-member operator fixes this because both operands are explicit parameters and both can be converted:

#include <iostream>
using namespace std;

class Money {
    long cents;
public:
    Money(long c) : cents(c) {}
    long value() const { return cents; }
    // grant the free function access to the private field
    friend Money operator+(const Money& a, const Money& b);
};

Money operator+(const Money& a, const Money& b) {
    return Money(a.cents + b.cents);
}

int main() {
    Money a(150);
    Money total = 50 + a;       // 50 converts to Money(50); now symmetric
    cout << total.value() << "\n";  // 200
}

Rule of thumb: make symmetric binary operators (+, ==, *) non-members so conversions work on both sides; make operators that must modify or are bound to the left operand (+=, [], =) members.

Overloading the Stream Operator

The single most common operator to overload is << for printing. You cannot make it a member of your class, because the left operand is a std::ostream (like cout), not your type - and you don't own ostream. So it's always a non-member taking the stream by non-const reference and returning it:

#include <iostream>
using namespace std;

struct Point {
    int x, y;
};

// left operand is the stream; return it so calls can chain
ostream& operator<<(ostream& os, const Point& p) {
    os << "(" << p.x << ", " << p.y << ")";
    return os;
}

int main() {
    Point p{3, 7};
    cout << "p = " << p << "\n";   // p = (3, 7)
}

Two details make this work. The stream is passed and returned by reference (ostream&) - streams can't be copied, and returning the same stream is what lets you chain cout << "p = " << p << "\n". Each << returns the stream so the next << has something to bind to. Forget the return os; and chaining breaks.

Comparison Operators

To compare your objects with ==, <, and friends, overload the comparison operators. Before C++20 you wrote each one by hand; the key gotcha is that operator< must return a bool and define a consistent ordering:

#include <iostream>
using namespace std;

struct Version {
    int major, minor;
};

bool operator==(const Version& a, const Version& b) {
    return a.major == b.major && a.minor == b.minor;
}

bool operator<(const Version& a, const Version& b) {
    if (a.major != b.major) return a.major < b.major;
    return a.minor < b.minor;        // tie-break on minor
}

int main() {
    Version v1{1, 4}, v2{1, 9};
    cout << (v1 == v2) << "\n";   // 0
    cout << (v1 < v2) << "\n";    // 1
}

Writing all six comparisons (==, !=, <, <=, >, >=) by hand is tedious and error-prone. C++20 added the three-way comparison operator <=> (the "spaceship"). Defaulting it plus == generates every comparison for you:

#include <compare>
#include <iostream>
using namespace std;

struct Version {
    int major, minor;
    auto operator<=>(const Version&) const = default;
    bool operator==(const Version&) const = default;
};

int main() {
    Version v1{1, 4}, v2{1, 9};
    cout << (v1 < v2)  << "\n";   // 1
    cout << (v1 >= v2) << "\n";   // 0
}

= default tells the compiler to compare members in declaration order, which is exactly the lexicographic ordering you'd write by hand. Prefer this on modern compilers.

The Assignment Operator and Its Traps

operator= (copy assignment) is special: the compiler generates one for you, and for simple classes that default is correct. You only need to write your own when your class manages a resource - raw memory, a file handle - where a member-by-member copy would be wrong. The canonical signature returns *this by reference so assignments can chain (a = b = c):

#include <iostream>
using namespace std;

class Buffer {
    int* data;
    int size;
public:
    Buffer(int n) : data(new int[n]), size(n) {}
    ~Buffer() { delete[] data; }

    Buffer& operator=(const Buffer& other) {
        if (this == &other) return *this;   // guard against self-assignment
        delete[] data;                      // free what we held
        size = other.size;
        data = new int[size];               // allocate fresh
        for (int i = 0; i < size; ++i) data[i] = other.data[i];
        return *this;                       // enable a = b = c
    }
    int length() const { return size; }
};

int main() {
    Buffer a(3), b(5);
    a = b;
    cout << a.length() << "\n";   // 5
}

Two traps live in this short function. First, the self-assignment check if (this == &other): without it, a = a would delete[] data and then read from the just-freed other.data - undefined behavior. Second, the order matters - in a hand-rolled version you must not delete the old buffer before you've safely copied the new one (a real implementation often allocates first, or uses the copy-and-swap idiom, so a failed allocation leaves the object intact).

A broader gotcha: don't overload operators in surprising ways. operator+ that secretly modifies its left operand, or operator== that isn't symmetric, will confuse every reader and break standard-library code that assumes the usual meanings. Overload operators only when the operation is genuinely "addition-like" or "equality-like" for your type.

Next: Access Specifiers

Notice how every example kept its data members private and exposed behavior through a small public surface - constructors, operators, and a few methods. That boundary between what's visible to the outside world and what's hidden inside the class is controlled by access specifiers: public, private, and protected. Next we'll look at exactly what each one allows, why private data with public methods is the default for good encapsulation, and how protected fits into inheritance.