Przeciążanie funkcji w C++: ta sama nazwa, różne parametry

Jedna nazwa, wiele wersji

Często potrzebujesz tej samej operacji dla różnych rodzajów danych: wypisać int, wypisać string, wypisać double. W niektórych językach wymyśla się wtedy printInt, printString, printDouble. C++ pozwala nadać im wszystkim tę samą nazwę i rozróżnia je po parametrach. To właśnie przeciążanie funkcji.

Reguła jest prosta: kilka funkcji może dzielić nazwę, o ile ich listy parametrów się różnią: liczbą parametrów, ich typami albo kolejnością. Kompilator patrzy na argumenty w każdym miejscu wywołania i wybiera za ciebie pasującą wersję.

#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
}

Trzy funkcje, jedna nazwa. Każde wywołanie trafia do wersji, której typ parametru pasuje do argumentu. Dzięki temu std::cout << x działa tak samo dla liczb całkowitych, zmiennoprzecinkowych i napisów: operator<< jest przeciążony wielokrotnie.

Co liczy się jako inne przeciążenie

Przeciążenie wyróżnia wyłącznie lista parametrów. Możesz zmieniać:

int  area(int side);                 // 1 parametr
int  area(int width, int height);    // 2 parametry  -> inne
double area(double r);               // inny typ -> inne

void log(string msg, int level);     // kolejność ma znaczenie...
void log(int level, string msg);     // ...więc to też jest inne

Każde z nich to legalne, odrębne przeciążenie. Kompilator tworzy zbiór kandydatów ze wszystkich funkcji o nazwie area, a potem dopasowuje je po liczbie i typie argumentów.

Sam typ zwracany nie wystarczy

Oto pułapka, na której potyka się prawie każdy: nie można przeciążać po typie zwracanym. Wartość zwracana nie bierze udziału w wyborze przeciążenia, bo kompilator decyduje, którą funkcję wywołać, na podstawie argumentów, zanim w ogóle spojrzy na to, co wraca.

int    convert(double x);   // OK
double convert(double x);   // BŁĄD: redefinicja, różni się tylko typ zwracany

To się nie skompiluje. Jeśli listy parametrów są identyczne, z punktu widzenia przeciążania obie deklaracje to ta sama funkcja i dostajesz błąd redefinicji. Aby rozgałęzić zachowanie po typie wyniku, zmień parametr (albo użyj szablonów lub rzutowania typu w miejscu wywołania).

Jak rozstrzyganie przeciążeń wybiera zwycięzcę

Gdy wywołujesz funkcję, kompilator ocenia każde możliwe przeciążenie i wybiera najlepsze dopasowanie. W przybliżeniu preferuje, w kolejności:

1. Dokładne dopasowanie (bez żadnej konwersji).
2. Promocję (np. char lub short -> int, float -> double).
3. Konwersję standardową (np. int -> double, double -> int, wskaźnik na klasę bazową).

Jeśli dokładnie jedno przeciążenie jest ściśle lepsze od wszystkich pozostałych, ono wygrywa. Zobacz, jak dokładne dopasowanie pokonuje konwersję:

#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  (dokładne dopasowanie)
    show(5.0);   // double version (dokładne dopasowanie)
    show('A');   // int version  ('A' jest promowane char -> int)
}

'A' to char, ale promocja do int ma wyższą rangę niż konwersja do double, więc wywołane zostaje przeciążenie int. Dzięki tym regułom rangowania rozstrzyganie przeciążeń zwykle "po prostu robi, co trzeba", a od czasu do czasu potrafi zaskoczyć.

Pułapka niejednoznaczności

Jeśli dwa przeciążenia są równie dobre, czyli żadne nie jest ściśle lepsze, kompilator odmawia zgadywania i zgłasza niejednoznaczne wywołanie (ambiguous call). Podręcznikowy przypadek to dwa przeciążenia, z których każde wymaga konwersji tej samej rangi:

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

f(0L);   // BŁĄD: niejednoznaczne, long -> int i long -> double to konwersje tej samej rangi

Ani int, ani double nie jest dokładnym dopasowaniem dla long, a obie konwersje mają tę samą rangę, więc wywołanie jest niejednoznaczne. Masz dwa czyste rozwiązania:

#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));  // usuń niejednoznaczność rzutowaniem -> int
    // albo dodaj przeciążenie z dokładnym dopasowaniem, np.  void f(long), które wygra bez dyskusji
}

Pokrewna niespodzianka: przekazywanie literału napisowego. void g(const string&) i void g(bool) oba zgłoszą się do obsługi g("hi"), a bool może wygrać, bo const char* konwertuje się na bool (niepusty wskaźnik -> true) w mniejszej liczbie kroków niż budowa std::string. Jeśli kiedyś zobaczysz, że literał napisowy tajemniczo wywołuje twoje przeciążenie bool, to właśnie dlatego: dodaj przeciążenie const char* albo const string&, aby przejęło dokładne dopasowanie.

Przeciążanie i argumenty domyślne źle się łączą

Argumenty domyślne nie zastępują przeciążania, a łączenie jednego z drugim tworzy niejednoznaczność. Każde z nich może obsłużyć to samo wywołanie, więc kompilator nie potrafi wybrać:

void connect(string host, int port = 8080);   // można wywołać z 1 argumentem
void connect(string host);                     // też można wywołać z 1 argumentem

connect("localhost");   // BŁĄD: niejednoznaczne, obie pasują do jednego argumentu

Dla danego kształtu wywołania wybierz jedno podejście. Używaj argumentów domyślnych, gdy zachowanie jest identyczne, a chodzi ci tylko o opcjonalne parametry; używaj przeciążania, gdy różne listy argumentów mają uruchamiać naprawdę różny kod. Pomieszanie ich tak, że dwie sygnatury kolidują przy tej samej liczbie argumentów, to gwarantowany błąd niejednoznaczności.

Jeszcze jedno rozróżnienie warto utrwalić: przeciążanie to nie nadpisywanie. Przeciążanie rozstrzyga się w czasie kompilacji spośród funkcji w tym samym zasięgu o tej samej nazwie, ale różnych parametrach. Nadpisywanie (overriding) zastępuje funkcję virtual w klasie pochodnej w czasie działania i wymaga tej samej sygnatury: to temat na później, przy funkcjach wirtualnych.

Dalej: lambdy

Przeciążanie daje jednej nazwie kilka typowanych implementacji wybieranych w czasie kompilacji. Czasem jednak w ogóle nie chcesz nazwanej funkcji: potrzebujesz malutkiej, jednorazowej funkcji zdefiniowanej dokładnie tam, gdzie jej używasz, często po to, by przekazać ją do algorytmu takiego jak sort. Tym właśnie są lambdy: anonimowe funkcje, które piszesz w miejscu, które przechwytują otaczające zmienne i które przekazujesz dalej w jednym wyrażeniu. Następnie zobaczysz, jak je pisać i kiedy wygrywają z pełną, nazwaną funkcją.