Function Overloading

Programming Language & Its Applications — C++ Constructs with Objects and Classes, NEC licence examination syllabus (Nepal Engineering Council).

Function Overloading

Several functions, one name, chosen by their arguments — resolved entirely at compile time.

🌍 Where this lives: you already use overloading constantly without noticing. Every time you write cout << 42 and then cout << "hello" and then cout << 3.14, three different operator<< functions are being selected — that is overloading doing the work. In C the same job needs three differently-named functions: compare C's abs, labs, llabs, fabs, fabsf with C++'s single std::abs that handles all of them. Python solves this differently again (one function, runtime type checks), which is why len() works on everything. Search "C++ overload resolution rules" when you want the full algorithm — it is surprisingly intricate.

What makes a valid overload

Two functions may share a name if their PARAMETER LISTS differ in at least one of: · the NUMBER of parameters · the TYPE of a parameter · the ORDER of parameter types int area(int side); ✔ 1 int int area(int len, int wid); ✔ 2 ints double area(double radius); ✔ 1 double void print(int i, char c); ✔ void print(char c, int i); ✔ order differs NOT valid overloads — the RETURN TYPE is not considered: int f(int); double f(int); ✗ error: cannot overload on return type alone Also not distinguishing: void g(int); and void g(const int); ✗ same void h(int a[]); and void h(int *a); ✗ same (decay) typedef int Num; void k(int); void k(Num); ✗ same type

overload.cpp

#include <iostream>
#include <string>

/* same job, different argument shapes */
int    area(int side)              { return side * side; }
int    area(int len, int wid)      { return len * wid; }
double area(double r)              { return 3.14159 * r * r; }
double area(double b, double h)    { return 0.5 * b * h; }

void show(int i)                { std::cout << "int    " << i << "\n"; }
void show(double d)             { std::cout << "double " << d << "\n"; }
void show(char c)               { std::cout << "char   " << c << "\n"; }
void show(const std::string& s) { std::cout << "string " << s << "\n"; }

int main() {
    std::cout << "square  side 5      = " << area(5)        << "\n";
    std::cout << "rect    4 x 6       = " << area(4, 6)     << "\n";
    std::cout << "circle  r = 2.0     = " << area(2.0)      << "\n";
    std::cout << "triangle b=3 h=8    = " << area(3.0, 8.0) << "\n";

    show(42); show(3.14); show('A'); show(std::string("hi"));
    return 0;
}
Output:
square  side 5      = 25
rect    4 x 6       = 24
circle  r = 2.0     = 12.5664
triangle b=3 h=8    = 12
int    42
double 3.14
char   A
string hi

Checking the numbers: square = 5² = 25 ✔ rect = 4 × 6 = 24 ✔ circle = π × 2² = 3.14159 × 4 = 12.56636 ✔ triangle = ½ × 3 × 8 = 12 ✔ Note area(4, 6) chose the int version and area(3.0, 8.0) chose the double version — same call shape, different types, different function. The compiler picked, not the runtime.

How the compiler chooses — overload resolution

Given a call, the compiler builds a set of candidates and ranks each argument conversion. Simplified ordering, best to worst: 1. EXACT match (or trivial: array→pointer, T→const T) 2. PROMOTION char→int, float→double, bool→int 3. STANDARD CONVERSION int→double, double→int, int→bool, Derived*→Base* 4. USER-DEFINED CONVERSION (a converting constructor) 5. ELLIPSIS (...) The best candidate must be strictly better than every other for at least one argument and no worse for any. If two candidates tie, the call is AMBIGUOUS — a compile error, not a runtime coin-flip. void f(int); void f(double); f(5); → exact match on int ✔ f(5.0); → exact match on double ✔ f('a'); → promotion char→int wins over char→double ✔ f(5.0f); → float→double is a promotion, beats float→int conversion ✔

resolution.cpp

#include <iostream>

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

void g(long)  { std::cout << "g(long)\n"; }
void g(float) { std::cout << "g(float)\n"; }

int main() {
    f(10);      /* exact          -> f(int)    */
    f(10.5);    /* exact          -> f(double) */
    f('x');     /* promotion      -> f(int)    */
    f(true);    /* promotion      -> f(int)    */
    f(10.5f);   /* promotion      -> f(double) */

    /* g(10) is AMBIGUOUS: int->long and int->float are
       BOTH standard conversions of equal rank.
       Uncomment to see the error: */
    /* g(10);   error: call to 'g' is ambiguous */
    g(10L);     /* exact -> g(long) */
    return 0;
}
Output:
f(int)
f(double)
f(int)
f(int)
f(double)
g(long)

Notice that f(10.5f) picks f(double), not f(int). It looks backwards — a float is "more like" an int in that both are numbers of the same size — but float→double is a promotion (rank 2, lossless) while float→int is a conversion (rank 3, lossy). The ranking is about information preserved, not about type similarity.

Worked example — overloading versus the C alternative

versus_c.cpp

#include <iostream>
#include <cmath>

/* THE C WAY: distinct names, caller must pick correctly.
     int    abs(int);
     long   labs(long);
     double fabs(double);
     float  fabsf(float);
   Pick the wrong one and you get silent truncation:
     fabs(-3.7) -> 3.7     but
     abs(-3.7)  -> 3       (argument truncated to int!) */

/* THE C++ WAY: one name, compiler picks */
int    my_abs(int x)    { return x < 0 ? -x : x; }
long   my_abs(long x)   { return x < 0 ? -x : x; }
double my_abs(double x) { return x < 0 ? -x : x; }

int main() {
    std::cout << my_abs(-7)     << "\n";   /* int    */
    std::cout << my_abs(-7L)    << "\n";   /* long   */
    std::cout << my_abs(-3.7)   << "\n";   /* double - EXACT */

    /* the C trap, reproduced deliberately */
    std::cout << "C-style abs(-3.7) would give "
              << my_abs(static_cast<int>(-3.7)) << "\n";
    return 0;
}
Output:
7
7
3.7
C-style abs(-3.7) would give 3

Name mangling — how the linker copes

Three functions named "show" cannot all be the symbol "show" in the object file. The compiler MANGLES each name, encoding the parameter types: void show(int) -> _Z4showi void show(double) -> _Z4showd void show(char) -> _Z4showc void show(std::string&) -> _Z4showRNSt7__cxx1112basic_... Reading _Z4showi: _Z = C++ marker 4 = length of "show" show i = int This is why: · overloading on RETURN TYPE is impossible — the return type is NOT part of the mangled name, so the two symbols would be identical · you need extern "C" to call C++ from C: it disables mangling so the symbol stays plain "show" Verify it yourself: g++ -c prog.cpp && nm prog.o | c++filt

🌍 Go further: overloading is resolved at compile time by argument types, which makes it fundamentally different from the overriding you will meet in the virtual-functions section — that is resolved at runtime by object type. Confusing the two is the single most common OOP exam mistake, and the distinction has a real cost: overloading is free (the compiler just picks a symbol), overriding costs one pointer indirection per call. Search "static vs dynamic polymorphism C++" to see both sides, and why template-based "static polymorphism" is how high-performance C++ avoids paying the runtime price.

💡 Exam angle: state the three ways parameter lists may differ (number, type, order) and — crucially — that the return type alone cannot distinguish overloads, with name mangling as the reason. Be ready to write a set of overloads (area for square/rectangle/circle/triangle is the classic) and to trace which overload a given call selects. Know that overloading is compile-time (static) polymorphism and contrast it with runtime overriding.

Syllabus points

Overloading rules; resolution

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.