Dlaczego metoda stała publiczna nie jest wywoływana, skoro metoda inna niż stała jest prywatna?

Rozważ ten kod:

struct A
{
    void foo() const
    {
        std::cout << "const" << std::endl;
    }

    private:

        void foo()
        {
            std::cout << "non - const" << std::endl;
        }
};

int main()
{
    A a;
    a.foo();
}

Błąd kompilatora to:

błąd: „void A :: foo ()” jest prywatne ”.

Ale kiedy usuwam prywatny, po prostu działa. Dlaczego metoda public const nie jest wywoływana, gdy metoda inna niż stała jest prywatna?

Innymi słowy, dlaczego rozwiązanie przeciążenia następuje przed kontrolą dostępu? To jest dziwne. Czy uważasz, że jest to spójne? Mój kod działa, a następnie dodaję metodę, a mój działający kod w ogóle się nie kompiluje.

Podczas wywołania a.foo();kompilator przechodzi przez rozwiązanie przeciążenia, aby znaleźć najlepszą funkcję do użycia. Podczas kompilowania znalezionego zestawu przeciążeń

void foo() const

i

void foo()

Ponieważ atak nie jest const, wersja inna niż stała jest najlepszym dopasowaniem, więc kompilator wybiera void foo(). Następnie wprowadzane są ograniczenia dostępu i pojawia się błąd kompilatora, ponieważ void foo()jest prywatny.

Pamiętaj, że w rozwiązaniu problemu z przeciążeniem nie chodzi o „znalezienie najlepszej użytecznej funkcji”. To „znajdź najlepszą funkcję i spróbuj jej użyć”. Jeśli nie może z powodu ograniczeń dostępu lub usunięcia, pojawia się błąd kompilatora.

Innymi słowy, dlaczego rozwiązanie przeciążenia następuje przed kontrolą dostępu?

Cóż, spójrzmy na:

struct Base
{
    void foo() { std::cout << "Base\n"; }
};

struct Derived : Base
{
    void foo() { std::cout << "Derived\n"; }
};

struct Foo
{
    void foo(Base * b) { b->foo(); }
private:
    void foo(Derived * d) { d->foo(); }
};

int main()
{
    Derived d;
    Foo f;
    f.foo(&d);
}

Powiedzmy teraz, że tak naprawdę nie chciałem robić void foo(Derived * d)czegoś prywatnego. Gdyby kontrola dostępu pojawiła się jako pierwsza, program ten skompilowałby się, uruchomiłby i Basezostałby wydrukowany. Może to być bardzo trudne do wyśledzenia w dużej bazie kodu. Ponieważ kontrola dostępu następuje po rozwiązaniu problemu z przeciążeniem, pojawia się miły błąd kompilatora, który mówi mi, że funkcja, którą chcę, aby wywołać, nie może zostać wywołana, a błąd jest znacznie łatwiejszy.

Ostatecznie sprowadza się to do stwierdzenia w standardzie, że dostępność nie powinna być brana pod uwagę podczas rozwiązywania problemu z przeciążeniem . To stwierdzenie można znaleźć w [over.match] klauzuli 3:

... Kiedy rozwiązanie przeciążenia powiedzie się, a najlepsza funkcjonalna funkcja nie jest dostępna (klauzula [class.access]) w kontekście, w którym jest używana, program jest źle sformułowany.

a także uwaga w punkcie 1 tej samej sekcji:

[Uwaga: Nie ma gwarancji, że funkcja wybrana przez rozwiązanie przeciążenia będzie odpowiednia dla kontekstu. Inne ograniczenia, takie jak dostępność funkcji, mogą spowodować, że jej użycie w kontekście wywołania będzie źle sformułowane. - notatka końcowa]

Jeśli chodzi o przyczyny, przychodzi mi do głowy kilka możliwych motywacji:

1. Zapobiega nieoczekiwanym zmianom zachowania w wyniku zmiany dostępności kandydata na przeciążenie (zamiast tego wystąpi błąd kompilacji).
2. Usuwa zależność od kontekstu z procesu rozpoznawania przeciążenia (tj. Rozpoznanie przeciążenia miałoby ten sam wynik w klasie, czy poza nią).

Załóżmy, że kontrola dostępu nastąpiła przed rozwiązaniem problemu przeciążenia. W rzeczywistości oznaczałoby to public/protected/privatekontrolowaną widoczność, a nie dostępność.

Sekcja 2.10 projektu i ewolucji C ++ autorstwa Stroustrupa zawiera fragment na ten temat, w którym omawia następujący przykład

int a; // global a

class X {
private:
    int a; // member X::a
};

class XX : public X {
    void f() { a = 1; } // which a?
};

Stroustrup wspomina, że korzyści wynikające z obowiązujących przepisów (widoczności przed dostępność) jest to, że (tymczasowo) chaning z privatewnętrza class Xdo public(na przykład dla celów debugowania) to, że nie ma żadnych zmian cicho w rozumieniu powyższego programu (czyli X::apróbuje się być dostępne w obu przypadkach, co daje błąd dostępu w powyższym przykładzie). Gdyby public/protected/privatekontrolował widoczność, znaczenie programu by się zmieniło (w przeciwnym razie global azostałby wywołany with ).privateX::a

Następnie stwierdza, że ​​nie przypomina sobie, czy było to spowodowane jawnym projektem, czy efektem ubocznym technologii preprocesora używanej do implementacji C z poprzednikiem Classess standardowego C ++.

Jak to się ma do twojego przykładu? Zasadniczo dlatego, że standardowe rozpoznawanie przeciążenia jest zgodne z ogólną zasadą, że wyszukiwanie nazw ma miejsce przed kontrolą dostępu.

10.2 Wyszukiwanie nazw członków [class.member.lookup]

1 Wyszukiwanie nazw składowych określa znaczenie nazwy (wyrażenie id) w zakresie klasy (3.3.7). Wyszukiwanie nazwy może skutkować niejednoznacznością, w którym to przypadku program jest źle sformułowany. W przypadku wyrażenia id, wyszukiwanie nazw zaczyna się w zakresie klasy this; w przypadku kwalifikowanego identyfikatora wyszukiwanie nazwy zaczyna się w zakresie zagnieżdżonego specyfikatora nazwy. Wyszukiwanie nazwy ma miejsce przed kontrolą dostępu (3.4, Klauzula 11).

8 Jeśli nazwa przeciążonej funkcji zostanie znaleziona jednoznacznie, to przed kontrolą dostępu następuje również rozwiązanie przeciążenia (13.3) . Niejednoznaczności często można rozwiązać, kwalifikując nazwę za pomocą nazwy klasy.

Ponieważ niejawny thiswskaźnik jest constinny niż -, kompilator najpierw sprawdzi obecność nie- constwersji funkcji przed constwersją.

Jeśli wyraźnie zaznaczyć nieprzestrzegania constjednego privatenastępnie uchwała nie powiedzie się, a kompilator nie będzie kontynuować poszukiwania.

Ważne jest, aby pamiętać o kolejności rzeczy, które się dzieją, czyli:

1. Znajdź wszystkie możliwe funkcje.
2. Wybierz najlepszą wykonalną funkcję.
3. Jeśli nie ma dokładnie jednej z najlepszych wykonalnych funkcji lub jeśli faktycznie nie można wywołać najlepszej wykonalnej funkcji (z powodu naruszenia dostępu lub funkcji będącej deleted), zakończy się niepowodzeniem.

(3) dzieje się po (2). Co jest naprawdę ważne, ponieważ w przeciwnym razie tworzenie funkcji deleted lub privatestałoby się w pewnym sensie bez znaczenia i znacznie trudniejsze do rozważenia.

W tym przypadku:

1. Realne funkcje to A::foo()i A::foo() const.
2. Najlepszą realną funkcją jest to, A::foo()że ta ostatnia obejmuje konwersję kwalifikacji na niejawnym thisargumencie.
3. Ale A::foo()jest privatei nie masz do niego dostępu, stąd kod jest źle sformułowany.

Sprowadza się to do dość podstawowej decyzji projektowej w C ++.

Podczas wyszukiwania funkcji w celu spełnienia wywołania kompilator przeprowadza takie wyszukiwanie:

1. Przeszukuje znaleźć pierwsze ¹ zakres, w którym istnieje coś o tej nazwie.

2. Kompilator znajduje wszystkie funkcje (lub funktory itp.) O tej nazwie w tym zakresie.

3. Następnie kompilator rozwiązuje przeciążenie, aby znaleźć najlepszego kandydata spośród znalezionych (niezależnie od tego, czy są dostępne, czy nie).

4. Na koniec kompilator sprawdza, czy wybrana funkcja jest dostępna.

Z powodu tej kolejności tak, możliwe jest, że kompilator wybierze przeciążenie, które jest niedostępne, mimo że istnieje inne przeciążenie, które jest dostępne (ale nie zostało wybrane podczas rozwiązywania przeciążenia).

Czy byłoby możliwe , aby robić rzeczy inaczej: tak, to niewątpliwie możliwe. Z pewnością doprowadziłoby to jednak do całkiem innego języka niż C ++. Okazuje się, że wiele pozornie niewielkich decyzji może mieć konsekwencje, które mają znacznie większy wpływ, niż mogłoby się początkowo wydawać oczywiste.

1. „Pierwszy” może być sam w sobie trochę skomplikowany, zwłaszcza gdy w grę wchodzą szablony, ponieważ mogą prowadzić do wyszukiwania dwufazowego, co oznacza, że ​​podczas wyszukiwania są dwa całkowicie oddzielne „korzenie”. Podstawowa idea jest dość prosta, choć: zacznij od najmniejszego zakresu otaczającego, i swój sposób pracy na zewnątrz, do większych i większych zakresów obejmujących.

Kontrola dostępu ( public, protected, private) nie wpływają na przeciążenie rozdzielczość. Kompilator wybiera, void foo()ponieważ jest to najlepsze dopasowanie. Fakt, że jest niedostępny, tego nie zmienia. Usunięcie go pozostawia tylko void foo() const, co jest wtedy najlepszym (tj. Jedynym) dopasowaniem.

W tym wezwaniu:

a.foo();

W każdej funkcji składowej zawsze dostępny jest niejawny thiswskaźnik. A constkwalifikacja thispochodzi z wywołującego odniesienia / obiektu. Powyższe wywołanie jest traktowane przez kompilator jako:

A::foo(a);

Ale masz dwie deklaracje, A::fooktóre są traktowane jak :

A::foo(A* );
A::foo(A const* );

Dzięki rozwiązaniu przeciążenia pierwsza zostanie wybrana jako inna niż stała this, a druga zostanie wybrana dla const this. Jeśli usuniesz pierwszy, drugi połączy się z obydwoma consti non-const this.

Po rozwiązaniu problemu z przeciążeniem, aby wybrać najlepszą wykonalną funkcję, następuje kontrola dostępu. Ponieważ określono dostęp do wybranego przeciążenia jako private, kompilator będzie narzekać.

Norma mówi tak:

[class.access / 4] : ... W przypadku przeciążonych nazw funkcji kontrola dostępu jest stosowana do funkcji wybranej przez rozwiązanie przeciążenia ....

Ale jeśli to zrobisz:

A a;
const A& ac = a;
ac.foo();

Wtedy constpasuje tylko przeciążenie.

Na powód techniczny odpowiedziały inne odpowiedzi. Skoncentruję się tylko na tym pytaniu:

Innymi słowy, dlaczego rozwiązanie przeciążenia następuje przed kontrolą dostępu? To jest dziwne. Czy uważasz, że jest to spójne? Mój kod działa, a następnie dodaję metodę, a mój kod roboczy w ogóle się nie kompiluje.

Tak zaprojektowano język. Celem jest próba wywołania najlepszego możliwego przeciążenia, tak dalece, jak to możliwe. Jeśli to się nie powiedzie, zostanie wyzwolony błąd, aby przypomnieć o ponownym rozważeniu projektu.

Z drugiej strony załóżmy, że Twój kod został skompilowany i działał dobrze z constwywoływaną funkcją składową. Któregoś dnia ktoś (może Ty) zdecyduje się zmienić dostępność funkcji niebędącej constczłonkiem z privatena public. Wtedy zachowanie zmieniłoby się bez błędów kompilacji! To byłaby niespodzianka .

Ponieważ zmienna aw mainfunkcji nie jest zadeklarowana jako const.

Stałe funkcje składowe są wywoływane na stałych obiektach.

Specyfikatory dostępu nigdy nie wpływają na wyszukiwanie nazw i rozpoznawanie wywołań funkcji. Funkcja jest wybierana zanim kompilator sprawdzi, czy wywołanie powinno wywołać naruszenie dostępu.

W ten sposób, jeśli zmienisz specyfikator dostępu, zostaniesz ostrzeżony w czasie kompilacji, jeśli nastąpi naruszenie w istniejącym kodzie; Gdyby wziąć pod uwagę prywatność przy rozwiązywaniu wywołań funkcji, zachowanie programu mogłoby się po cichu zmienić.