🚀 go-pugleaf

W dniu 07.06.18r. o 18:52, Piotr Gałka pisze:
> W dniu 2018-06-07 o 15:42, radoslaw@korzeniewski.net pisze:
>> W dniu czwartek, 7 czerwca 2018 15:35:11 UTC+2 użytkownik Piotr Gałka 
>> napisał:
>>> Dla mnie dziwne.
>>> Skoro B nie ma send() to powinna zawołać się send() z A (jeśli 
>>> publiczna).
>>> Ta powinna zawołać send(int), a że ta jest wirtualna to powinna zawołać
>>> się ta z B.
>>
>> Dokładnie taki sam tok myślenia przeprowadziłem ale niestety generuje 
>> to błąd podczas kompilacji. Zakładam że to ja jestem w błędzie i 
>> dlatego poszukuję pomocy.
>>
> 
> Sprawdziłem pod C++ Builder 5 (który używam) i jest tak samo jak u Ciebie.
> Wychodzi na to, że zapewne użycie tej samej nazwy w klasie pochodnej 
> zasłania wszystkie funkcje o takiej nazwie z kasy bazowej.
> Chodzi mi po głowie, że mogłem kiedyś coś takiego wiedzieć, ale wiedza 
> nie używana ulatuje (o dziedziczeniu uczyłem się z książki od C do C++, 
> którą kupiłem w 93r.).
> P.G.

Tak wlasnie jest w C++ (odwrotnie niz w Javie, tam by to dzialalo). I 
nawet jest na to uzasadnienie. Zalozmy, ze mamy takie cos:

	struct A { void f(long); };
	struct B : A { void f(long); };

	B b;
	b.f(0);

Oczywiscie zawola sie B::f. Teraz przypuscmy, ze nagle ktos postanowil 
do klasy A dolozyc funkcje void f(int);. Gdyby B::f nie przykrywalo 
wszystkich wersji A::f to w tym momencie zawolaloby sie A::f(int) i 
zmienia sie dzialanie naszego programu (0 jest int-em, wczesniej bylo 
niejawnie rzutowane na longa). Jezeli teraz spojrzymy na A jak na 
interfejs a na B jak na implementacje, to zmiana czegos w interfejsie 
moze rozwalic caly program. Co wiecej tak samo by bylo gdyby w A 
wczesniej w ogole nie bylo funkcji f. Dolozenie f(int) by wszystko 
rozwalilo. Jeszcze dolozmy do tego, ze tworca A raczej nie musi wiedziec 
jak jego interfejs jest uzywany, wiec moze dokladac co chce. Az dziw, ze 
programy w Javie dzialaja po upgradzie API :)

Marcin