On Jul 5, 4:24 pm, "slawek" <h...@s...pl> wrote:
> Użytkownik "Andrzej Jarzabek"  napisał w wiadomości grup
> dyskusyjnych:7a3451d2-b497-461a-8a6e-b79d7ffda...@a1
6g2000vby.googlegroups.com...
>
> >Pewną dość oczywistą wadą 'uruchomienia przez konstruktor' jest brak
> >możliwości sensownego dziedziczenia po takiej klasie. W C++ dodatkowo
> >w takich przypadkach występuje problem z wywoływaniem funkcji
> >wirtualnych z konstruktora.
>
> Ale przecież konstruktor tej klasy może być sparametryzowany i jednocześnie
> domyślny konstruktor może być pusty. No problem.

Problem jest taki, że jeśli w klasie potomnej w konstruktorze wywołasz
ów pusty konstruktor, to tracisz dostęp do swojego 'run' - nie
skonstruujesz klasy bazowej dwa razy.

> Chyba vtable jest już wypełniona przed wejściem w blok {} konstruktora? Bo i
> niby czemu nie miałaby być?!

Powody mogłyby być, natomiast np. w C++ będzie to vtable dla aktualnie
konstruowanej klasy, a nie dla końcowego typu obiektu, który jest
konstruowany. Czyli jeśli masz klasę B, która wywołuje swój 'run' w
konstruktorze, tworzysz dziedziczącą po niej klasę D, która nadpisuje
funkcje wirtualne klasy B, to wywołania tych funkcji w 'run' nadal
wywołują funkcje zdediniowane dla B, nie te dla D. Nie mówiąc już o
pięknej okazji do wprowadzenia UB jeśli klasa jest abstrakcyjna.

W Javie jest inaczej, ale niekoniecznie lepiej: cała klasa
inicjalizowana jest przed konstrukcją i metody są wywoływane dla
ostatecznego typu, ale to znaczy, że trzeba przewidzieć
'nieskonstruowany' stan klasy: nie możesz np. założyć, że jakas
referencja jest nie-null, jeśli ustawiasz jej wartość w konstruktorze.