zastanow sie, skad bierze sie crash typu 'nullpointer'..
musi byc jakas wartosc rowna zeru, cos potem musi ja potraktowac jako wskaznik i sprobowac odczytac/zapisac cos do pamieci pod ten adres.
calkiem mozliwe jest, ze:
{int* blah = 0;*blah;}
nie wywali wyjatku/bledu. *blah nie wykonuje nic, kompilator moze je "wy-optymalizowac" i nic z tego nie zostanie, program poleci dalej jak gdyby nigdy nic tam nie bylo napisane. zgadza sie?
to teraz spojrz na te swoje metody:
metody istnieja zawsze i ich kod jest znany podczas dzialania programu.
kod metody "klasa::zwroc_zmienna" jest osiagalny zawsze [dobra, pomijam dll'ki] i skadkolwiek.
to znaczy, ze teoretycznie 'skoczyc' do tej metody mozesz zawsze, skadkolwiek, najwyzej cos sie wywali -- np. poniewaz ta metoda spodziewa sie ze bedzie wywolana w jakis okreslony sposob, ze parametry beda takie a siakie, etc
jesli napiszesz metode, ktora NIE KORZYSTA ze wskaznika this, np. int x(){return 5;} - czemu ona mialaby sie wywalic jesli this == 0x00000000 ? program skoczyl do metody, napotkal natychmiast return 5; i koniec. podobnie u Ciebie - zaden element metody nie uzywa this, tzn. nie probuje wykonac (*this) ktore to NIE zostaloby "wy-optymalizowane", wiec nie ma nikogo kto by zauwazyl ze this jest nullptr'em. nic wiecej, zero magii.
gorzej, jesli ta metoda bylaby wirtualna jak jej poprzedniczna :) wtedy do jej odpalenia potrzebny jest this!=0, poniewaz runtime musi znalezc vtable..
edit: "wy-optymalizowane" - tzn. zauwazone jako niepotrzebne i nic niewnoszace, i przez to calkowicie usuniete z wyniku kompilacji