Lesson 6	Overloading member functions
Objective	Overload member functions in the same class.

Overloading Member Functions in C++

Introduction to Function Overloading

C++ enables several functions of the same name to be defined within the same scope, provided they have different signatures. This powerful feature, called function overloading, allows programmers to create multiple functions with the same name that perform similar operations on different data types or different numbers of parameters. The C++ compiler selects the appropriate function to call by examining the number, types, and order of the arguments in the function call through a process called overload resolution.

Function overloading is particularly valuable for creating intuitive interfaces. Instead of requiring separate function names like squareInt(), squareDouble(), and squareLong(), you can simply name all versions square() and let the compiler determine which to call based on the argument type. The C++ Standard Library makes extensive use of overloading—for example, the mathematical functions in <cmath> are overloaded to accept float, double, and long double arguments, and output stream operators are overloaded for all built-in types.

A function's signature consists of its name and its parameter list (the number, types, and order of parameters). Importantly, the return type is not part of the signature for overload resolution purposes. Two functions cannot be overloaded based solely on differing return types—they must differ in their parameter lists.

Basic Function Overloading Example

Consider a simple example of overloading a square function to handle both integers and floating-point values:

#include <iostream>
using namespace std;

// Function square for int values
int square(int x) {
    cout << "square of integer " << x << " is ";
    return x * x;
}

// Function square for double values
double square(double y) {
    cout << "square of double " << y << " is ";
    return y * y;
}

int main() {
    cout << square(7) << endl;      // Calls int version
    cout << square(7.5) << endl;    // Calls double version
    return 0;
}

Output:

square of integer 7 is 49
square of double 7.5 is 56.25

In this example, C++ treats the literal value 7 as type int, so the first call invokes square(int). The literal 7.5 is treated as type double, triggering the square(double) version. The compiler performs this selection at compile time based on the argument types, ensuring zero runtime overhead.

Overloading Member Functions Within a Class

Member functions within the same class can be overloaded using the same principles as free functions. The function name remains identical, but the parameter lists differ. This is particularly useful for providing multiple ways to perform the same logical operation with different inputs.

Consider a stack class that provides both a standard pop() operation and an optimized version that pops multiple elements at once:

class ch_stack {
private:
    static const int max_len = 100;
    char s[max_len];
    int top;
    
public:
    ch_stack() : top(0) { }
    
    void push(char c);
    char pop();              // Pop single element
    char pop(int n);         // Pop n elements, return the last
    bool isEmpty() const { return top == 0; }
    int size() const { return top; }
};

// Pop single element
char ch_stack::pop() {
    assert(top > 0);
    return s[--top];
}

// Pop n elements and return the final one
char ch_stack::pop(int n) {
    assert(n <= top);
    while (n-- > 1) {
        top--;
    }
    return s[--top];
}

The compiler selects which pop() to call based on the arguments provided:

ch_stack data;
// ... push some data ...

char ch1 = data.pop();      // Invokes pop()
char ch2 = data.pop(5);     // Invokes pop(int)

This design allows the same logical operation (removing elements from the stack) to be expressed with different parameter requirements, improving code clarity and usability.

Const-Qualified Member Function Overloads

One of the most important forms of member function overloading involves const qualification. A class can provide both const and non-const versions of the same member function, allowing different behavior depending on whether the object is const or non-const:

class StringWrapper {
private:
    std::string data;
    
public:
    StringWrapper(const std::string& str) : data(str) { }
    
    // Non-const version: returns modifiable reference
    char& operator[](size_t index) {
        return data[index];
    }
    
    // Const version: returns read-only reference
    const char& operator[](size_t index) const {
        return data[index];
    }
    
    // Non-const version: allows modification
    std::string& getString() {
        return data;
    }
    
    // Const version: read-only access
    const std::string& getString() const {
        return data;
    }
};

void demonstrate() {
    StringWrapper str("Hello");
    const StringWrapper cstr("World");
    
    char c1 = str[0];       // Calls non-const operator[]
    str[0] = 'h';           // OK: non-const returns char&
    
    char c2 = cstr[0];      // Calls const operator[]
    // cstr[0] = 'w';       // Error: const returns const char&
}

This pattern is fundamental in C++ for implementing const-correctness. The non-const version returns a modifiable reference, while the const version returns a read-only reference. The compiler automatically selects the appropriate version based on whether the object is const-qualified. This enables containers and data structures to provide efficient, non-copying access while still respecting const semantics.

Reference-Qualified Overloads (C++11)

C++11 introduced reference qualifiers (& and &&) that allow overloading based on whether the object is an lvalue or rvalue. This enables optimization for temporary objects:

class DataBuffer {
private:
    std::vector<int> data;
    
public:
    DataBuffer(std::initializer_list<int> init) : data(init) { }
    
    // Called on lvalue objects - returns const reference (no copy)
    const std::vector<int>& getData() const & {
        std::cout << "Returning const reference (lvalue)\n";
        return data;
    }
    
    // Called on rvalue objects - moves data out (efficient for temporaries)
    std::vector<int> getData() && {
        std::cout << "Moving data (rvalue)\n";
        return std::move(data);
    }
};

void demonstrate() {
    DataBuffer buffer({1, 2, 3, 4, 5});
    
    // Lvalue call - returns const reference
    auto data1 = buffer.getData();
    
    // Rvalue call - moves data
    auto data2 = DataBuffer({10, 20, 30}).getData();
}

The & qualifier restricts the function to lvalue objects (named objects with persistent addresses), while && restricts it to rvalue objects (temporary objects about to be destroyed). This allows the rvalue version to move resources efficiently, knowing the object won't be used afterward. This pattern is particularly valuable for getters that return large objects or resources.

Overloading with Default Parameters

Default parameters provide an alternative to overloading in some cases, but combining them with overloading requires caution to avoid ambiguity:

class Logger {
public:
    // Using default parameters
    void log(const std::string& message, int level = 0) {
        std::cout << "[Level " << level << "] " << message << "\n";
    }
    
    // Overloaded version for different types
    void log(int errorCode) {
        std::cout << "[Error Code: " << errorCode << "]\n";
    }
};

void demonstrate() {
    Logger logger;
    logger.log("Starting application");        // Uses default level = 0
    logger.log("High priority task", 3);       // Explicit level
    logger.log(404);                           // Calls int version
}

Ambiguity Warning: Avoid this pattern:

class BadExample {
public:
    void process(int x) { }
    void process(int x, int y = 0) { }  // Ambiguous!
};

// BadExample be;
// be.process(5);  // Error: ambiguous - could call either version

When a single-argument call could match multiple overloads (one directly, one through default parameters), the compiler reports an ambiguity error. Prefer one approach: either use default parameters or overload completely separate signatures.

Deleted Function Overloads (C++11)

C++11's = delete syntax allows you to explicitly disable certain overloads, preventing implicit conversions or restricting usage:

class SafeInteger {
private:
    int value;
    
public:
    SafeInteger(int v) : value(v) { }
    
    // Accept int
    void setValue(int v) { value = v; }
    
    // Explicitly delete double conversion to prevent precision loss
    void setValue(double) = delete;
    
    // Explicitly delete pointer overload
    void setValue(void*) = delete;
};

void demonstrate() {
    SafeInteger num(42);
    num.setValue(100);      // OK
    // num.setValue(3.14);  // Error: use of deleted function
    // num.setValue(nullptr); // Error: use of deleted function
}

Deleting specific overloads prevents unwanted implicit conversions and makes APIs safer. This is particularly useful for preventing accidental data loss (like double-to-int conversion) or preventing unintended behavior (like passing pointers when integers are expected). The compiler produces clear error messages indicating the function is deleted, making the intent explicit.

Overload Resolution Rules

When multiple overloads exist, the compiler follows a specific ranking process to determine the best match:

1. Exact Match (Highest Priority)

Argument types match parameter types exactly
Trivial conversions allowed (array-to-pointer, function-to-pointer, qualification conversions)

2. Promotion

char, short → int
float → double

3. Standard Conversion

Numeric conversions (int → double, long → int)
Pointer conversions (derived-to-base, nullptr → pointer)

4. User-Defined Conversion

Single user-defined conversion operator or converting constructor

5. Ellipsis Match (Lowest Priority)

Variadic function (... parameters)

Example:

class Overloaded {
public:
    void process(int x) { std::cout << "int version\n"; }
    void process(double x) { std::cout << "double version\n"; }
    void process(char x) { std::cout << "char version\n"; }
};

void demonstrate() {
    Overloaded obj;
    obj.process(42);        // Exact match: int version
    obj.process(3.14);      // Exact match: double version
    obj.process('A');       // Exact match: char version
    obj.process(42L);       // Standard conversion: long → int
    obj.process(3.14f);     // Promotion: float → double
}

If multiple overloads rank equally well, the call is ambiguous, and the compiler reports an error. This typically happens when multiple standard conversions could apply or when template and non-template versions compete.

Template Function Overloading

Function templates can participate in overload resolution alongside regular functions. Non-template functions are preferred when they match exactly:

template<typename T>
T maximum(T a, T b) {
    std::cout << "Template version\n";
    return (a > b) ? a : b;
}

// Explicit overload for double
double maximum(double a, double b) {
    std::cout << "Double version\n";
    return (a > b) ? a : b;
}

void demonstrate() {
    maximum(5, 10);         // Template: maximum<int>
    maximum(5.5, 10.5);     // Non-template: exact match preferred
    maximum(5L, 10L);       // Template: maximum<long>
}

The compiler first checks for exact-match non-template functions before considering templates. If no exact match exists, template argument deduction occurs, and the template is instantiated. This allows you to provide optimized implementations for specific types while maintaining generic template versions as a fallback.

Perfect Forwarding and Overloading

C++11's perfect forwarding can interact unexpectedly with overload resolution due to universal references being extremely greedy in template argument deduction:

class Wrapper {
private:
    std::string data;
    
public:
    // Constructor from string
    Wrapper(const std::string& str) : data(str) {
        std::cout << "Copy constructor\n";
    }
    
    // Perfect forwarding constructor
    template<typename T>
    Wrapper(T&& value) : data(std::forward<T>(value)) {
        std::cout << "Forwarding constructor\n";
    }
};

void demonstrate() {
    std::string str = "test";
    Wrapper w1(str);              // Ambiguous without constraints!
    // Template may be preferred due to better match
}

Solution: Use SFINAE or Concepts (C++20):

// C++20 approach with concepts
class Wrapper {
private:
    std::string data;
    
public:
    Wrapper(const std::string& str) : data(str) { }
    
    template<typename T>
    requires (!std::is_same_v<std::decay_t<T>, Wrapper> &&
              !std::is_same_v<std::decay_t<T>, std::string>)
    Wrapper(T&& value) : data(std::forward<T>(value)) { }
};

The requires clause prevents the template from matching Wrapper or std::string arguments, eliminating ambiguity. This is a common pattern when combining perfect forwarding with traditional constructors.

Member Function Lifetime and Overloading

A crucial point about member functions: there is no distinct copy of a member function for each object. When you create multiple objects of the same class, they share the same member function code:

ch_stack s, t, u;  // Three separate objects

This declaration creates three separate ch_stack objects, each with its own data members (s[] array and top index). However, all three objects share the same member function code. The this pointer distinguishes which object a member function call operates on. This design is memory-efficient—you don't pay storage costs for function code per object, only for data.

Member functions that don't modify the object should be declared const. These are called inspectors or accessor functions, as opposed to mutators or modifier functions for non-const member functions. Following this principle enables const-correctness and allows your class to work properly with const objects and references.

Common Pitfalls and Best Practices

Pitfall 1: Return Type Doesn't Matter

class BadExample {
public:
    int getValue();
    double getValue();  // Error: differs only in return type
};

Overloads must differ in their parameter lists. Return type alone is insufficient for overload resolution.

Pitfall 2: Ambiguous Calls

class Ambiguous {
public:
    void process(int x, double y = 0.0) { }
    void process(int x) { }
};

// Ambiguous a;
// a.process(5);  // Error: could match either overload

Avoid overlapping default parameters with overloading.

Pitfall 3: Implicit Conversion Traps

class NumberHandler {
public:
    void process(short s) { std::cout << "short\n"; }
    void process(long l) { std::cout << "long\n"; }
};

// NumberHandler nh;
// nh.process(42);  // Ambiguous: int converts to both short and long

Provide overloads for commonly used types to avoid ambiguity.

Best Practices:

Make const correctness a priority—overload on const qualification
Use deleted functions to prevent unwanted conversions
Prefer one style: either default parameters or separate overloads, not both
Document which overload is the "canonical" version if there are many variants
Consider reference qualifiers for expensive-to-copy return types
Use concepts (C++20) to constrain template overloads and improve error messages

Modern C++ Overloading with Concepts (C++20)

C++20 concepts provide a clean way to constrain template overloads, making overload resolution more predictable and error messages clearer:

#include <concepts>

template<typename T>
concept Numeric = std::integral<T> || std::floating_point<T>;

template<typename T>
concept StringLike = std::convertible_to<T, std::string_view>;

class Processor {
public:
    // Overload for numeric types
    void process(Numeric auto value) {
        std::cout << "Processing number: " << value << "\n";
    }
    
    // Overload for string-like types
    void process(StringLike auto value) {
        std::cout << "Processing string: " << value << "\n";
    }
};

void demonstrate() {
    Processor p;
    p.process(42);              // Calls Numeric version
    p.process(3.14);            // Calls Numeric version
    p.process("hello");         // Calls StringLike version
    p.process(std::string("world")); // Calls StringLike version
}

Concepts make template constraints explicit and prevent the template from participating in overload resolution for incompatible types. This eliminates many ambiguity issues and produces far better error messages than SFINAE-based approaches. The compiler can determine which overload applies based on the concept constraints, making code more maintainable and debuggable.

Summary

Function overloading is a fundamental C++ feature that enables multiple functions with the same name to coexist within the same scope, provided they have different parameter lists. Member function overloading works identically to free function overloading, allowing classes to provide intuitive, flexible interfaces. The compiler selects the appropriate overload through a well-defined resolution process that ranks matches by exactness, from perfect matches down through conversions to variadic functions.

Key aspects of member function overloading include:

Signatures differ by number, types, or order of parameters (return type doesn't count)
Const-qualification creates distinct overloads (critical for const-correctness)
Reference qualifiers (&, &&) enable lvalue/rvalue-specific overloads (C++11)
Deleted functions (= delete) prevent unwanted conversions (C++11)
Template functions participate in overload resolution with specific ranking rules
Concepts (C++20) constrain template overloads cleanly and improve diagnostics

Modern C++ has enhanced overloading with reference qualifiers, deleted functions, perfect forwarding, and concepts. These features enable more expressive, safer APIs while maintaining the zero-overhead principle. Mastering function overloading—including understanding overload resolution rules, avoiding ambiguities, and leveraging modern features—is essential for writing idiomatic, efficient C++ code that provides intuitive interfaces to users.

Remember that while overloading is powerful, clarity should remain the priority. Provide overloads when they genuinely enhance usability, but avoid creating complex overload sets that confuse users or lead to ambiguous calls. Well-designed overloading makes code more natural to use; poorly designed overloading creates maintenance burdens and subtle bugs.