🚀 go-pugleaf

Dnia Thu, 15 Nov 2007 00:32:51 +0000 (UTC)
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
napisał(a):

> > No i wewnątrz funkcji zamiast do member drugiego elementu tablicy
> > funkcja dostaje się do member2 pierwszego elementu tablicy. Może
> > niespecjalnie mnie to dziwi (i dlatego też myślę, że "działa dobrze"
> > może oznaczać, że psuje się jak powinno), ale szkoda, że nawet
> > warninga nie ma...
> 
> Moment - na co przepraszam chcesz mieć warning?
Było by fajnie dostać po głowie za, chociażby, upcastowanie
wskaźnika na tablicę obiektów. Albo za użycie [] na wskaźniku obiektu,
który znajduje się w jakiejś hierarchii obiektów.

Abstrahuję od realizowalności takiego warninga.
> 
> Zdecyduj ty się może, czy przekazujesz pojedynczy obiekt, czy
> przekazujesz wskazanie na pojedynczy element tablicy
Wskazanie na pierwszy element tablicy - jej początek. Funkcja może
nawet za argument brać struct bar x[], co nic nie zmieni.

> (i, co ważniejsze, wiesz na pewno, że za nim znajdują się w tej
> tablicy jeszcze co najmniej dwa elementy).
Ilość elementów nie gra roli -- ją mogę przekazać jako drugi parametr
lub jako NULL pod ostatnim adresem tablicy.

> Oczywiście, nikt nie będzie zaprzeczał, że zunifikowanie iteratora do
> tablicy z wskaźnikiem na pojedynczy obiekt, jest poważną wadą -
> istnieje jednak od początków języka C i jak zatwierdzano standard,
> nikt nie widział w tym żadnego problemu.
Pytanie czy właśnie nie powinien widzieć. ;) (Mówię o standardzie C++,
w C - ok)

> A C++ nie był w stanie
> niczego z tym zrobić. W C++ i tak jest duży postęp przez to, że nie
> można domyślnie konwertować niespokrewnionych wskaźników.
"No jest zepsute. Ale przecież mogło być znacznie gorzej"

> 
> > Czy metodologię testowania mam zepsutą? ;/
> 
> 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<>.

> Ciesz się, jeśli kompilator rzuci warning, że
> konwertujesz różne typy wskaźnikowe (bo nie musi rzucać - w ANSI C
> nie jest to błąd).
A to inna sprawa jest.

> W przypadku C++ można się tego ustrzec o tyle, o ile się będzie
> pamiętać, żeby nie stosować operatora [] na typie X* - jeśli się
> miało na myśli tablicę, należy jawnie napisać, że chodzi o iterator.
> W takim przypadku przynajmniej nie będzie można takiego programu
> skompilować.
No tak. Jedyny problem jest taki, że można zrobić tak jak w tym kodzie i
nikt nas (prócz segmentation fault) nie poinformuje, że zrobiliśmy
cokolwiek źle.

Pozdrawiam.
-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be