🚀 go-pugleaf

Tomasz bla Fortuna wrote:
>>W przypadku języka C, faktycznie, nie jesteś w stanie ustrzec się
>>takiego błędu.
> 
> W C takiego błędu by nie było. W C bym nie upcastował nigdy wskaźnika
> na klasę. Bo.. no nie ma klas. Jeśli funkcja dostaje wskaźnik do
> tablicy elementów A typu T i jej wielkość to A[0] to pierwszy
> element, a A[1] to drugi element, a nie dalszy kawałek A[0], który
> okazał się być jednak innego typu niż T.
> 
> A nawet jakbym rzutował w C większe structy na mniejsze to nie jest to
> tak naturalne jak w C++ upcasting. W Idealnych warunkach ten przykład
> nie powinien się skompilować bez zastosowania reinterpret_cast<>.

Tak powinno być, gdyby w C++ nie było tego poważnego błedu projektowego.

Można to było rozwiązać na różne sposoby.

Np, jeśli już koniecznie musimy akurat ten quirk z C przejmować (wywalając 
parę innych, takich jak typ funkcja(), konwersje między różnymi wskaźnikami, 
itd) to można było choć w wprowadzić jakieś sensowne rozróżnienie na POD i 
nie-POD. Naprzykład takie class to jest w zasadzie to samo co
struct { private:. Nic więc nie wnosi. A gdyby struct było zawsze POD, a 
class nigdy POD i dla nie-POD odróżnić twardo * od [] (przy okazji w class 
wywalić domyślny konstruktor kopiujący i przypisanie) byłoby już lepiej.


pzdr
\SK