Kiedy wywołanie funkcji członkowskiej w instancji o wartości null powoduje niezdefiniowane zachowanie?

Rozważ następujący kod:

#include <iostream>

struct foo
{
    // (a):
    void bar() { std::cout << "gman was here" << std::endl; }

    // (b):
    void baz() { x = 5; }

    int x;
};

int main()
{
    foo* f = 0;

    f->bar(); // (a)
    f->baz(); // (b)
}

Spodziewamy (b)się awarii, ponieważ nie ma odpowiedniego elementu członkowskiego xdla wskaźnika pustego. W praktyce (a)nie ulega awarii, ponieważ thiswskaźnik nigdy nie jest używany.

Ponieważ (b)wyłuskiwanie thispointer ( (*this).x = 5;) i thisjest null, program wprowadza niezdefiniowane zachowanie, ponieważ dereferencjonowanie null jest zawsze uważane za niezdefiniowane zachowanie.

Ma (a)doprowadzić do nieokreślonego zachowania? A co jeśli obie funkcje (i x) są statyczne?

Obie (a)i (b)powodują niezdefiniowane zachowanie. Wywołanie funkcji składowej za pomocą wskaźnika pustego jest zawsze niezdefiniowanym zachowaniem. Jeśli funkcja jest statyczna, również jest technicznie niezdefiniowana, ale istnieje spór.

Pierwszą rzeczą do zrozumienia jest to, dlaczego odwołanie do pustego wskaźnika jest niezdefiniowanym zachowaniem. W C ++ 03 jest tu właściwie trochę niejednoznaczności.

Mimo że „dereferencjonowanie pustego wskaźnika skutkuje niezdefiniowanym zachowaniem” jest wspomniane w uwagach w obu §1.9 / 4 i §8.3.2 / 4, nigdy nie zostało to wyraźnie powiedziane. (Uwagi są nienormatywne.)

Można jednak spróbować wywnioskować to z § 3.10/2:

Wartość l odnosi się do obiektu lub funkcji.

Podczas dereferencji wynikiem jest lwartość. Wskaźnik zerowy nie odnosi się do obiektu, dlatego kiedy używamy lvalue, mamy niezdefiniowane zachowanie. Problem w tym, że poprzednie zdanie nigdy nie zostało wypowiedziane, więc co to znaczy „używać” lwartości? Po prostu wygeneruj go w ogóle, czy użyj go w bardziej formalnym sensie wykonywania konwersji lwartości na rwartość?

Niezależnie od tego zdecydowanie nie można go przekonwertować na wartość r (§4.1 / 1):

Jeśli obiekt, do którego odnosi się lwartość, nie jest obiektem typu T i nie jest obiektem typu wywodzącego się z T lub jeśli obiekt nie jest zainicjowany, program, który wymaga tej konwersji, ma niezdefiniowane zachowanie.

Tutaj jest to zdecydowanie niezdefiniowane zachowanie.

Niejednoznaczność wynika z tego, czy jest to niezdefiniowane zachowanie, aby uszanować, ale nie używa wartości z nieprawidłowego wskaźnika (to znaczy, pobiera lwartość, ale nie konwertuje jej na rwartość). Jeśli nie, to int *i = 0; *i; &(*i);jest dobrze zdefiniowane. To jest aktywny problem .

Mamy więc ścisły widok „wyłuskiwanie wskaźnika zerowego, uzyskanie niezdefiniowanego zachowania” i słaby widok „użyj wyłuskanego wskaźnika zerowego, uzyskaj niezdefiniowane zachowanie”.

Teraz rozważymy pytanie.

Tak, (a)skutkuje niezdefiniowanym zachowaniem. W rzeczywistości, jeśli thisjest null, to niezależnie od zawartości funkcji wynik jest niezdefiniowany.

Wynika to z §5.2.5 / 3:

Jeśli E1ma typ „wskaźnik do klasy X”, wówczas wyrażenie E1->E2jest konwertowane na równoważną formę(*(E1)).E2;

*(E1)spowoduje niezdefiniowane zachowanie ze ścisłą interpretacją i .E2przekształci je na wartość r, co spowoduje niezdefiniowane zachowanie w przypadku słabej interpretacji.

Wynika z tego również, że jest to niezdefiniowane zachowanie bezpośrednio z (§9.3.1 / 1):

Jeśli niestatyczna funkcja składowa klasy X jest wywoływana dla obiektu, który nie jest typu X lub typu pochodnego od X, zachowanie jest niezdefiniowane.

W przypadku funkcji statycznych różnica polega na interpretacji ścisłej i słabej. Ściśle mówiąc, jest niezdefiniowany:

Do statycznego elementu członkowskiego można się odwoływać przy użyciu składni dostępu do elementu członkowskiego klasy, w którym to przypadku obliczane jest wyrażenie obiektu.

Oznacza to, że jest oceniany tak, jakby był niestatyczny i po raz kolejny wyłuskujemy wskaźnik zerowy z (*(E1)).E2.

Jednak ponieważ E1nie jest używany w statycznym wywołaniu funkcji składowej, jeśli używamy słabej interpretacji, wywołanie jest dobrze zdefiniowane. *(E1)daje lwartość, funkcja statyczna jest rozwiązywana,*(E1) odrzucana i wywoływana. Nie ma konwersji lwartości na rwartość, więc nie ma niezdefiniowanego zachowania.

W C ++ 0x, od n3126, niejednoznaczność pozostaje. Na razie bądź bezpieczny: stosuj ścisłą interpretację.

Oczywiście nieokreślony oznacza, że nie jest zdefiniowany , ale czasami może być przewidywalny. Informacje, które zamierzam podać, nigdy nie powinny być oparte na działającym kodzie, ponieważ z pewnością nie jest to gwarantowane, ale mogą się przydać podczas debugowania.

Można by pomyśleć, że wywołanie funkcji na wskaźniku obiektu spowoduje wyłuskiwanie wskaźnika i spowoduje UB. W praktyce, jeśli funkcja nie jest wirtualna, kompilator przekształci ją w zwykłe wywołanie funkcji, przekazując wskaźnik jako pierwszy parametr this , omijając wyłuskiwanie i tworząc bombę zegarową dla wywoływanej funkcji składowej. Jeśli funkcja składowa nie odwołuje się do żadnych zmiennych składowych ani funkcji wirtualnych, może się powieść bez błędu. Pamiętaj, że sukces mieści się w uniwersum „nieokreślonego”!

Funkcja MFC firmy Microsoft GetSafeHwnd faktycznie opiera się na tym zachowaniu. Nie wiem, co palili.

Jeśli wywołujesz funkcję wirtualną, wskaźnik musi zostać wyłuskany, aby dostać się do tabeli vtable, i na pewno otrzymasz UB (prawdopodobnie awaria, ale pamiętaj, że nie ma żadnych gwarancji).