🚀 go-pugleaf

Jedrzej Dudkiewicz wrote:
>> Przykazywany jest wskaźnik na obiekt klasy pochodnej do funkcji 
>> oczekującej wskaźnika na obiekt klasy bazowej -- to jest *standardowe* 
>> użycie polimorfizmu. To, że funkcja oczekuje przekazania tablicy, 
>> tylko przygłupi, kulawy język nie miesza tablice ze wskaźnikami to 
>> jest to co jest.
> 
> Wydaje mi się, że o ile przykład pokazuje prawdziwy problem, to sam jest 
> idiotyczny, tzn. strasznie wydumany. W C++, nawet gdyby tablice były 
> obsługiwane prawidłowo, tj. nie byłoby rzutowania (niejawnego) wskaźnika 
> na tablicę, to ten przykład chyba byłby ciągle marny:
> 
> class A {};
> class B : public A {
> public:
>     void do_me() { };
> };
> 
> B tablica[3];
> 
> void fun(A tablica[])
> {
>     tablica[0].do_me(); // <- co z tym?
> }

To się nie skompiluje z dwu powodów:
1. A nie ma metody do_me(), ale to jest, jak rozumiem, przeoczenie
2. Choć A jest nadtypem B, to w poprawionym C++ tablica A nie jest nadtypem 
tablicy B. Podobnei jak i dziś A** nie jest żadnym nadtypem **B.


> Znaczy - trzebaby niejawnie jakoś konwertować to na wskaźniki... No nie 
> wiem, jakaś porażka. Czyli jeszcze raz - o ile przedstawiony problem 
> jest prawdziwy, to przykład jest całkiem z kosmosu - stąd łatwo się go 
> czepiać.

W dobrym języku przykłąd byłby nierealizowalny bez reinterpet_cast. Dziś 
jest to po prostu dziura w systemie typów.


>> To jest karygodny błąd języka. Tłumaczenie wielbicieli C++, żeby użyć 
>> ciężkiego wektora czy niewiele lżejszego, ale w ogóle nie należącego 
>> do języka boost::array jest poprostu żałosne.
> 
> A co jest ciężkiego w vectorze? To nie zaczepka, tylko ciekawość, żeby 
> nie było.

1. Alokacja sterty
2. Powiększanie.
3. Brak kurczenia.

Np. zastąpienie wektora dedykowaną klasą (ciągle z alokacją sterty, ale z 
lepszym powiększaniem i kurczeniem, zoptymalizowanej do trzymania typów POD) 
dało mi w Śmieciuchu++ zysk rzędu 30%.

pzdr
\SK