C++ Function Overloading: Same Name, Different Parameters

One Name, Many Versions

You often need the same operation for different kinds of data: print an int, print a string, print a double. In some languages you'd invent printInt, printString, printDouble. C++ lets you give all of them the same name and tells them apart by their parameters. That's function overloading.

The rule is simple: several functions may share a name as long as their parameter lists differ - in the number of parameters, their types, or their order. The compiler looks at the arguments at each call site and picks the matching version for you.

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

void print(int x) {
    cout << "int: " << x << "\n";
}

void print(double x) {
    cout << "double: " << x << "\n";
}

void print(const string& x) {
    cout << "string: " << x << "\n";
}

int main() {
    print(42);          // int: 42
    print(3.14);        // double: 3.14
    print(string("hi")); // string: hi
}

Three functions, one name. Each call lands on the version whose parameter type fits the argument. This is what makes std::cout << x work for ints, doubles, and strings alike - operator<< is overloaded many times over.

What Counts as a Different Overload

An overload is distinguished by its parameter list only. You can vary:

int  area(int side);                 // 1 param
int  area(int width, int height);    // 2 params  -> different
double area(double r);               // different type -> different

void log(string msg, int level);     // order matters...
void log(int level, string msg);     // ...so this is different too

Each of those is a legal, distinct overload. The compiler builds a candidate set from all functions named area, then matches by argument count and type.

Return Type Alone Is Not Enough

Here's the gotcha that trips up almost everyone: you cannot overload on return type. The return value plays no part in choosing the overload, because the compiler decides which function to call from the arguments - before it ever looks at what comes back.

int    convert(double x);   // OK
double convert(double x);   // ERROR: redefinition - only the return type differs

That won't compile. If the parameter lists are identical, the two declarations are the same function as far as overloading is concerned, and you get a redefinition error. To branch on the result type, change a parameter (or use templates / a type cast at the call site instead).

How Overload Resolution Picks a Winner

When you make a call, the compiler ranks every viable overload and chooses the best match. Roughly, it prefers, in order:

1. An exact match (no conversion needed).
2. A promotion (e.g. char or short -> int, float -> double).
3. A standard conversion (e.g. int -> double, double -> int, pointer-to-base).

If exactly one overload is strictly better than all others, that one wins. Watch how an exact match beats a conversion:

#include <iostream>
using namespace std;

void show(int x)    { cout << "int version\n"; }
void show(double x) { cout << "double version\n"; }

int main() {
    show(5);     // int version  (exact match)
    show(5.0);   // double version (exact match)
    show('A');   // int version  ('A' promotes char -> int)
}

'A' is a char, but a promotion to int outranks a conversion to double, so it calls the int overload. These ranking rules are why overload resolution usually "just does the right thing" - and occasionally surprises you.

The Ambiguity Trap

If two overloads are equally good - neither strictly better - the compiler refuses to guess and reports an ambiguous call. The textbook case is two overloads that each need a same-rank conversion:

void f(int x);
void f(double x);

f(0L);   // ERROR: ambiguous - long -> int and long -> double are equal-rank conversions

Neither int nor double is an exact match for long, and both conversions sit at the same rank, so the call is ambiguous. You have two clean fixes:

#include <iostream>
using namespace std;

void f(int x)    { cout << "int\n"; }
void f(double x) { cout << "double\n"; }

int main() {
    f(static_cast<int>(0L));  // disambiguate with a cast -> int
    // or add an exact-match overload like  void f(long)  to win outright
}

A related surprise: passing a string literal. void g(const string&) and void g(bool) will both bid for g("hi"), and bool can win, because a const char* converts to bool (non-null -> true) with fewer steps than building a std::string. If you ever see a string literal mysteriously calling your bool overload, this is why - add a const char* or const string& overload to take the exact match.

Overloading and Default Arguments Don't Mix Well

Default arguments are not a substitute for overloading, and combining the two creates ambiguity. Each can answer the same call, so the compiler can't choose:

void connect(string host, int port = 8080);   // can be called with 1 arg
void connect(string host);                     // also callable with 1 arg

connect("localhost");   // ERROR: ambiguous - both match a single argument

Pick one approach per call shape. Use default arguments when the behavior is identical and you just want optional parameters; use overloading when the different argument lists should run genuinely different code. Mixing them so that two signatures collide for the same call count is a guaranteed ambiguity error.

One more distinction worth nailing down: overloading is not overriding. Overloading resolves at compile time among functions in the same scope with the same name but different parameters. Overriding replaces a virtual function in a derived class at run time and requires the same signature - a topic for virtual functions later.

Next: Lambdas

Overloading gives one name several typed implementations chosen at compile time. Sometimes, though, you don't want a named function at all - you need a tiny throwaway function defined right where you use it, often to pass into an algorithm like sort. That's exactly what lambdas are: anonymous functions you can write inline, capture surrounding variables with, and hand off in a single expression. Next we'll see how to write them and when they beat a full named function.