C++ Function Overloading

Function overloading lets you give several functions the same name as long as they take different parameters. The compiler figures out which version to run based on the number, types, and order of the arguments you pass at each call site. This means you can write add(int, int) and add(double, double) side by side, and callers simply write add(...) without worrying about which one executes. Overloading is one of the ways C++ achieves compile-time polymorphism, letting your code read naturally instead of being cluttered with awkward names like addInts and addDoubles.

Overview / How It Works

C++ allows multiple functions to share a single name inside the same scope, provided their parameter lists are distinguishable. Two functions count as different overloads if they differ in at least one of the following: the number of parameters, the type of at least one parameter, or the order of parameter types when the types themselves differ. The return type is not part of a function’s signature for overload purposes — you cannot have two functions with the same name and the exact same parameter list that differ only in what they return.

Internally, the compiler tells overloaded functions apart using a technique called name mangling (also called name decoration). When you write add(int, int) and add(double, double), the compiler doesn’t emit a plain symbol called add for both — it encodes the parameter types into a unique internal name, something like _Z3addii for the int version and _Z3adddd for the double version (the exact scheme is compiler-specific, but the idea is universal across C++ toolchains). This is why overloading is a purely compile-time mechanism: by the time the linker runs, each overload already has its own distinct symbol, and there is no runtime lookup or dispatch involved — the specific function to call is decided and hard-wired into the machine code at compile time. It is also why extern "C" functions cannot be overloaded: C linkage disables name mangling, since the C linker expects a plain, undecorated name.

When the compiler sees a call such as add(2, 3.5), it builds a candidate set of every function named add visible in scope, discards the ones that are not viable (wrong number of arguments, or arguments that cannot convert to the parameter types at all), and then ranks each remaining viable candidate by how good the required conversion is for every argument, from best to worst: an exact match, a match via promotion (such as char to int, or float to double), a match via a standard conversion (such as int to double), a match via a user-defined conversion (a converting constructor or conversion operator), and finally a match via the ellipsis (...) fallback. The overload whose conversions are collectively best across all arguments wins. If two or more candidates are equally good, the call is ambiguous and the compiler rejects it outright — it never silently guesses.

Syntax

returnType functionName(parameterList1) { /* ... */ }
returnType functionName(parameterList2) { /* ... */ }
// as many overloads as needed, each with a distinguishable parameter list

What differs between two declarations	Valid overload?
Number of parameters	Yes
Type of at least one parameter	Yes
Order of two differing parameter types (e.g. `(int, double)` vs `(double, int)`)	Yes
Only the parameter names	No — names aren’t part of the signature; this is a redefinition error
Only the return type	No — compile error
Only a top-level `const` on a by-value parameter (e.g. `f(int)` vs `f(const int)`)	No — identical from the caller’s point of view

Examples

Example 1: Basic overloading by type and count

#include <iostream>
using namespace std;

int add(int a, int b) {
    return a + b;
}

double add(double a, double b) {
    return a + b;
}

int add(int a, int b, int c) {
    return a + b + c;
}

int main() {
    cout << "add(2, 3) = " << add(2, 3) << endl;
    cout << "add(2.5, 3.5) = " << add(2.5, 3.5) << endl;
    cout << "add(1, 2, 3) = " << add(1, 2, 3) << endl;
    return 0;
}

Output:

add(2, 3) = 5
add(2.5, 3.5) = 6
add(1, 2, 3) = 6

Three functions share the name add. The compiler picks the two-int version for add(2, 3), the two-double version for add(2.5, 3.5), and the three-int version for add(1, 2, 3) purely by matching argument count and type — there is no runtime branching here at all.

Example 2: Overloading across different data types

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

void print(int value) {
    cout << "Integer: " << value << endl;
}

void print(double value) {
    cout << "Double: " << value << endl;
}

void print(const string& value) {
    cout << "String: " << value << endl;
}

void print(const char* value) {
    cout << "C-string: " << value << endl;
}

int main() {
    print(42);
    print(3.14);
    print(string("hello"));
    print("world");
    return 0;
}

Output:

Integer: 42
Double: 3.14
String: hello
C-string: world

Notice that print("world") calls the const char* overload, not the string one, even though a string could be constructed from the literal. An exact match (the literal is already a const char*) always beats a match that requires a user-defined conversion, so the compiler prefers the more direct overload.

Example 3: A realistic case — computing volumes for different shapes

#include <iostream>
using namespace std;

double volume(double side) {
    return side * side * side;
}

double volume(double length, double width, double height) {
    return length * width * height;
}

double volume(double radius, double height, bool isCylinder) {
    const double PI = 3.14159265358979;
    return PI * radius * radius * height;
}

int main() {
    cout << "Cube volume: " << volume(3.0) << endl;
    cout << "Box volume: " << volume(2.0, 3.0, 4.0) << endl;
    cout << "Cylinder volume: " << volume(2.0, 5.0, true) << endl;
    return 0;
}

Output:

Cube volume: 27
Box volume: 24
Cylinder volume: 62.8319

Here three geometrically different formulas share the name volume, distinguished purely by parameter count and type. This is exactly the kind of situation overloading is meant for: the same conceptual operation (“compute a volume”) applied to different shapes, without inventing three unrelated function names.

Under the Hood: Overload Resolution Step by Step

The compiler collects every function named X that is visible at the call site into a candidate set.
It discards candidates that are not viable — wrong number of arguments, or an argument with no possible conversion to the parameter type.
For each remaining viable candidate, it ranks the conversion needed for every single argument.
A candidate is the overall best match if, for every argument, its conversion rank is at least as good as every other candidate’s, and strictly better for at least one argument.
If a unique best match exists, that exact function’s mangled symbol is embedded into the generated machine code — the decision is permanent and made before the program ever runs.
If no viable candidate exists, or two candidates are equally good, the compiler stops with an error: “no matching function” or “call is ambiguous.”

Rank (best to worst)	Example
Exact match	`int` argument to `int` parameter
Promotion	`char` to `int`, `float` to `double`
Standard conversion	`int` to `double`, pointer conversions
User-defined conversion	`const char*` to `std::string` via constructor
Ellipsis match	matches a `(...)` parameter as a last resort

This is fundamentally different from virtual function dispatch, which is resolved at runtime through a vtable lookup based on an object’s dynamic type. Overload resolution is entirely static — it only ever looks at the compile-time types of the arguments.

Common Mistakes

Mistake 1: Trying to overload by return type alone

int getValue() {
    return 42;
}

double getValue() {
    return 42.5;
} // error: functions that differ only in return type cannot be overloaded

The compiler only looks at the parameter list to distinguish overloads, so two zero-parameter functions named getValue are considered redefinitions of each other, regardless of what they return. The fix is to give them genuinely distinct names or parameters:

#include <iostream>
using namespace std;

int getIntValue() {
    return 42;
}

double getDoubleValue() {
    return 42.5;
}

int main() {
    cout << "Int: " << getIntValue() << endl;
    cout << "Double: " << getDoubleValue() << endl;
    return 0;
}

Output:

Int: 42
Double: 42.5

Mistake 2: Letting a default argument collide with an overload

void greet(const string& name) {
    cout << "Hello, " << name << "!" << endl;
}

void greet(const string& name, const string& title = "Friend") {
    cout << "Hello, " << title << " " << name << "!" << endl;
}

int main() {
    greet("Sam"); // error: ambiguous — matches both overloads equally well
    return 0;
}

Once title has a default value, calling greet("Sam") can match either the one-parameter overload or the two-parameter overload with its default filled in — both are equally good matches, so the compiler refuses to pick one. The fix is usually to drop the redundant overload and rely on the default argument alone:

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

void greet(const string& name, const string& title = "Friend") {
    cout << "Hello, " << title << " " << name << "!" << endl;
}

int main() {
    greet("Sam");
    greet("Sam", "Dr.");
    return 0;
}

Output:

Hello, Friend Sam!
Hello, Dr. Sam!

Best Practices

Only overload a name when the operations are conceptually the same task performed on different inputs — don’t reuse a name for unrelated behavior just because it’s convenient.
Never try to differentiate overloads by return type; the compiler enforces this, so design your API around parameters from the start.
Keep the meaning and order of parameters consistent across every overload of the same name, so callers can guess the right one without checking documentation.
Be careful mixing default arguments with overloading — check every possible call shape for ambiguity before shipping.
Watch for implicit conversions (an int literal silently matching a double overload, a char converting to int) picking an overload you didn’t intend.
When the logic is identical regardless of type, prefer a function template over writing many nearly identical overloads by hand.
Document behavioral differences between overloads if they do more than just accept a different type (for example, a three-argument overload that changes the formula, not just adds a parameter).

Practice Exercises

Exercise 1: Write two overloaded functions named larger — one that returns the larger of two int values, and one that returns the larger of two double values. Call both in main() with larger(4, 9) and larger(2.5, 1.1) and print the results.
Exercise 2: Write three overloaded functions named area: area(double side) for a square, area(double length, double width) for a rectangle, and area(double base, double height, char shape) for a triangle (use 0.5 * base * height when shape is 't'). Call all three and print each result.
Exercise 3 (predict the output): Given void show(int x), void show(double x), and void show(char x), predict what each of these prints, then compile to check yourself: show(5);, show(5.5f);, show('A');, show(5.0);. Hint: think about which conversion — exact match or promotion — applies to the float argument.

Summary

Function overloading lets multiple functions share a name as long as their parameter lists differ in number, type, or the order of differing types.
Return type alone never distinguishes overloads — the compiler rejects two functions that differ only in what they return.
Overload resolution happens entirely at compile time by ranking each argument’s required conversion (exact match > promotion > standard conversion > user-defined conversion > ellipsis) and choosing the single best-matching function.
The compiler distinguishes overloads internally through name mangling, giving each one a unique linker symbol.
Ambiguous calls, where no overload is unambiguously best, are compile-time errors, not runtime surprises.
Default arguments can silently create ambiguity with an existing overload — check combined signatures carefully.
Use overloading for genuinely equivalent operations on different types, and reach for templates when the logic is truly identical across types.

C++ Function Overloading

Overview / How It Works

Syntax

Examples

Example 1: Basic overloading by type and count

Example 2: Overloading across different data types

Example 3: A realistic case — computing volumes for different shapes

Under the Hood: Overload Resolution Step by Step

Common Mistakes

Mistake 1: Trying to overload by return type alone

Mistake 2: Letting a default argument collide with an overload

Best Practices

Practice Exercises

Summary

Table of Contents