Lesson 2	Why overload operators?
Objective	Understand the utility of operator overloading and apply it safely in modern C++.

Operator Overloading in C++: Utility and Modern Practice

Operator overloading lets user-defined types behave more like built-in types. When used correctly, it makes custom abstractions intuitive and expressive. But misuse leads to confusion, poor maintainability, and violations of encapsulation. This lesson explains why operator overloading exists, when it is appropriate, and how to use it responsibly with modern C++ practices.

Why Overload Operators?

Just as functions can be given multiple meanings through overloading, operators can be extended to work with user-defined types. For example:

a + b could mean integer addition, string concatenation, or complex number addition depending on the types involved.
Overloading << allows objects to be directly streamed to std::cout.
Overloading [] lets custom containers act like arrays.

Operator overloading enhances abstraction and consistency by letting code read naturally, mirroring built-in syntax.

Operator Overloading Example

Below is a before-and-after example showing why overloading improves readability.


class MyNum {
public:
    int val;
    explicit MyNum(int i) : val(i) {}
    MyNum add(const MyNum& other) const {
        return MyNum(val + other.val);
    }
};

// Without operator overloading
MyNum a(10), b(5);
MyNum c = a.add(b);

By defining operator+, we achieve more intuitive syntax:


class MyNum {
public:
    int val;
    explicit MyNum(int i) : val(i) {}
    friend MyNum operator+(const MyNum& lhs, const MyNum& rhs) {
        return MyNum(lhs.val + rhs.val);
    }
};

// With operator overloading
MyNum a(10), b(5);
MyNum c = a + b;  // cleaner and more familiar

Key Guidelines

Preserve expectations: Overloaded operators should behave consistently with their built-in meanings (e.g., + should not sort).
Return types correctly: Assignment-like operators (=, +=, []) should return by reference to support chaining.
Use friend selectively: For symmetric operators, consider hidden friends. Otherwise, prefer const observers or member functions to preserve encapsulation.
Prefer clarity: Avoid “clever” overloads that hide complexity or surprise maintainers.
Follow RAII: When operators manage resources (e.g., deep copies with operator=), ensure exception safety and ownership semantics with smart pointers or standard containers.

Modern Enhancements

Spaceship operator: With C++20, define operator<=> to get all six comparison operators automatically.
noexcept and constexpr: Mark overloads as noexcept and/or constexpr when possible for performance and correctness.
Inline hidden friends: Use hidden friend definitions for operators to enable argument-dependent lookup (ADL) without polluting the global namespace.
Prefer composition over overloads: Sometimes a named function is clearer than an operator, especially for domain-specific or nonstandard behavior.

When Not to Overload

Operator overloading should be avoided when:

The operation is domain-specific and not obvious (e.g., overloading % to mean “concatenate files”).
The readability gain is less than the potential for confusion.
Named functions (e.g., merge(), transform()) better express the intent.