Dlaczego funkcja overridden w klasie pochodnej ukrywa inne przeciążenia klasy bazowej?

Sądząc po treści twojego pytania (użyłeś słowa "Ukryj"), już wiesz, co się tutaj dzieje. Zjawisko to nazywane jest "ukrywaniem nazw". Z jakiegoś powodu, za każdym razem, gdy ktoś zadaje pytanie o dlaczego ukrywanie nazw ma miejsce, ludzie, którzy odpowiadają albo mówią, że to się nazywa" ukrywanie nazw "i wyjaśniają jak to działa (co prawdopodobnie już wiesz), albo wyjaśniają jak to nadpisać (o co nigdy nie pytałeś), ale nikt nie dba o to, aby zająć się faktycznym "dlaczego ukrywanie nazw"?" pytanie.

Decyzja, uzasadnieniem ukrywania nazwy, tj. dlaczego została ona zaprojektowana w C++, polega na unikaniu pewnych nieprzewidzianych, nieprzewidzianych i potencjalnie niebezpiecznych zachowań, które mogłyby mieć miejsce, gdyby odziedziczony zestaw przeciążonych funkcji mógł mieszać się z bieżącym zestawem przeciążeń w danej klasie. Zapewne wiesz, że w C++ rozdzielczość przeciążeń działa poprzez wybór najlepszej funkcji z zestawu kandydatów. Odbywa się to poprzez dopasowanie typy argumentów do typów parametrów. Reguły dopasowywania mogą być czasami skomplikowane i często prowadzić do wyników, które mogą być postrzegane jako nielogiczne przez nieprzygotowanego użytkownika. Dodanie nowych funkcji do zestawu wcześniej istniejących może spowodować dość drastyczną zmianę wyników rozdzielczości przeciążenia.

Na przykład, powiedzmy, że klasa bazowa B ma funkcję member foo, która pobiera parametr typu void *, a wszystkie wywołania do foo(NULL) są rozwiązywane do B::foo(void *). Powiedzmy, że jest no name hiding i to {[5] } jest widoczne w wielu różnych klasach malejących z B. Jednak powiedzmy, że w pewnym [pośrednim, odległym] potomku {[8] } klasy B zdefiniowana jest funkcja foo(int). Teraz, bez ukrywania nazwy D ma zarówno foo(void *), jak i foo(int) widoczne i biorące udział w rozwiązywaniu przeciążeń. Do której funkcji zostaną wywołane wywołania foo(NULL), jeśli zostaną wykonane przez obiekt typu D? Rozwiążą się do D::foo(int), ponieważ int jest lepszym dopasowaniem do zera całkowego (tj. NULL) niż jakiekolwiek typ wskaźnika. Tak więc, w całej hierarchii wywołania foo(NULL) rozwiązują się do jednej funkcji, podczas gdy w D (i pod) nagle rozwiązują się do innej.

class Base {
    int x;
public:
    virtual void copy(Base* p) { x = p-> x; }
};

class Derived{
    int xx;
public:
    virtual void copy(Derived* p) { xx = p->xx; Base::copy(p); }
};

void f(Base a, Derived b)
{
    a.copy(&b); // ok: copy Base part of b
    b.copy(&a); // error: copy(Base*) is hidden by copy(Derived*)
}

Bez tej reguły stan b byłby częściowo zaktualizowany, co prowadziłoby do krojenia.

To zachowanie zostało uznane za niepożądane, gdy język został zaprojektowany. Jako lepsze podejście, zdecydowano się podążać za specyfikacją "ukrywanie nazwy" , co oznacza, że każda klasa zaczyna się od "czystego arkusza" w odniesieniu do każdej nazwy metody, którą deklaruje. Aby nadpisać to zachowanie, wymagane jest jawne działanie od użytkownika: pierwotnie ponowne deklarowanie odziedziczonych metod (obecnie przestarzałych), teraz jawne użycie using-declaration.

Jak słusznie zauważyłeś w swoim oryginalnym poście (mam na myśli uwagę "nie polimorficzną"), to zachowanie może być postrzegane jako naruszenie relacji IS-a pomiędzy klasami. To jest prawda, ale najwyraźniej wtedy zdecydowano, że w końcu ukrywanie nazw okaże się mniejszym złem.