🚀 go-pugleaf

Sektor van Skijlen wrote:
>In pl.comp.lang.c Adam Karpierz <karpierz@itl.pl> wrote:
>: Sektor van Skijlen wrote:
>:>In pl.comp.lang.c Adam Michalski <aimsoft@box43.gnet.pl> wrote:
>:>: Oj kolego, nie wyglaszaj takich kategorycznych stwierdzen...
>:>: przypomnij sobie jakie miales problemy z dwuwymiarowymi tablicami i
>:>: wskaznikami...
>:>: PNMSP
>:>
>:>To nie ma nic do rzeczy. Tablice wielowymiarowe sa problematyczne przez wzglad
>                                   ^^^^^^^^^^^^^^
>:>na to, ze sa to typy wyzszego rzedu. Poza tym tablice nie maja nic wspolnego z
>:>referencjami. Referencje to temat az nadto prosty.
>
>: Boze... Tablice w C to typy wyzszego rzedu ?.  O zgrozo !
>: Prymitywy najnizszego rzedu z mozliwych.
>: Nie ma chyba drugiego jezyka w ktorym by byly tak prymitywnie
>: (bo przez wskazniki) zrealizowane.
>
>Moj drogi Adamie. Wielu rozmowcow tym swoim lenistwem podczas czytania
>doprowadzilbys do bialej goraczki; mnie wystarczylo, ze doprowadziles siebie
>do samokompromitacji. Wyraznie napisalem: TABLICE WIELOWYMIAROWE, czyli
>conajmniej dwuwymiarowe.

Czlowieku kochany :).
Tablice 2 i 3 i N wymairowe sa jeszcze bardziej prymitywne jak
jednowymiarowe. To po prostu rowniez w swym charakterze twor podobny
jak pointer rownie prymitywny jak i w tablicy jednowymiarowej tyle ze gorszy bo
trzeba oprocz niego (nazwy) przekazywac w deklaracjach graniczne wymiary tejze
"tablicy wyzszego rzedu" (oprocz pierwszego).
Nie jest wiec mozliwe napisanei ogolnej funkcji dzialacej na tablicy wiecej niz
jednowymiarowej dla tablic ze zmiennymi wymiarami (oprocz pierwszego).
Wlasnosc ta wynika w prostej mierze wlasnei z tego ze tablica
(kazda) to nic innego w chrakterze jak pointer i kompilator musi znac maks
rozmiar kazdego wymiaru aby poprawnei obliczyc adres elementu.

Jezeli dla Ciebie twor typu.
int tab[3][4];
do ktorego elementu np tab[1][2]
mozna sie odwolywac zarowno przez
tab[1][2] jak i rownie dobrze tab[0][6]
jak i tab[2][-2] a nawet tab[47][-182]
jest tworem wyzszego rzedu to ja dziekuje bardzo
Po prostu zapis tab[i][j] jest przez kompilator wykonywany
jako *(((int *) addr(tab)) + 4 * i + j) i mozna sobie dowolnie dobierac
i i j byle 4*i + j wyszo na  rowne 6 (dla eelmentu [1][2]

Dlatego tez PRAKTYCZNIE tablice w C/C++ nei nadaja sie do uzycia.
Dlatego tez trzeba uzywac tablic pointerow w numeryce aby wlasnie nie
dostac bialej goraczki o ktorej piszesz.
Tyle ze tablice pointerow to znow horror optymalnego przydzielania pamieci.

Widac ze nic nie wyniosles z niedawnej dyskusji wlasnie o tablicach
wielowymiarowych w C jaka tu (na pl.comp.lang.c) sie niedawno toczyla i w
ktorej  (delikatnie mowiac) nei wykazales sie "zbytnia znajomoscia" tematu.
Swiadkowie sa. DejaNews tez nie klamie.

>Jesli ktos zas nie pamieta, przypomne, ze swego rodzaju dyskusja odbyla sie tu
>swego czasu nt. wskaznikow i tablic wielowymiarowych, w ktorej wyszly
>(nieoficjalnie, bo w koncu nie napisalem podsumowania) nastepujace rzeczy:

Bardzo dobrze ze go nei napisales wtedy i jeszcze gorzej ze go probujesz
napisac teraz bo jest po prostu... eh...

>1. Tablica wielowymiarowa jest typem wyzszego rzedu.

Smiech na sali. Uzasadneinei j/w.

>2. Nie mozna tworzyc typow nastepnego rzedu, jezeli typ poprzedniego rzedu
>jest typem niekompletnym.

Nic nie rozumiem

>3. Tablica i wskaznik maja rownowazne typy, lecz sa to zmienne o innym
>charakterze.

Nie maja rownowaznego typu !. One jedynie w charakterze zachowuja
sie jak pointer. Przeciez to juz tyle walkowalismy !.

Zmienne:
int tab [2][4];
i
int **tab;
to sa zupelnie rozne typu .
Podobnie zmienne.
int tab[1][3];
i
int tab[1][5];
sa _innego_ typu.

>Tak, Adamie... ponarzekaj jeszcze na to, ze zmienne trzeba w C przekazywac
>przez wskaznik (jesli chce sie przekazac zmienne), ze funkcja qsort potrzebuje
>jawnie otrzymac rozmiar tablicy i ich elementow, ze trzeba robic tyle
>przeksztalcen... na jezyk C mozna jeszcze dlugo narzekac.

Alez oczywiscie !. To wszystko co piszesz to prawda i newatpliwe wady !.
Tyle ze ja ne narzekam na C bo on ma dobra strukture
do tego do czego zostal stworzony i w nim sa potrzebne i pointery i wiele
innych bardzo niskopoziomowych mechanizmow bo toc przeciez
po prostu strukturalny assembler wiec musi siedziec blisko architektury/
charakteru procesora.  Narzekam natomiast zdecydowanie na C++ ktory bez
zmruzenia okiem wszytkie te zle cechy przejal wprost
nei probujac ich naprawic a probuje pretendowac do jezyka wysokiego poziomu.
Przykladem tablice (takie same jak w C) , typ string ktory dopierow 10 lat po
ukazaniu sie C++ doczekal sie standaryzacji,
neidorobione referencje przez co nie pozwalajace uwolnic sie od wskaznikow
i niebezpieczenstwa ich arytmetyki nawet gdy nei jest nam ona do niczego
potrzebna, mozna tak wymeinaic wiele...

>: Sa i zalety (szybki dostep) ale czy rownowazy to wady ?.
>W C++ - tak. Bo w C++ mozna te wady wyeliminowac.

Nieprawda. Nie do konca. Uzasadnial to juz A.L. kiedys i przychylam sie
do jego zdania.
Nie da sie napisac naprawde optymalnej obslugi tablic jesli nie jest ona
zaszyta w jezyku/kompilatorze. Po prostu strata informacji o tablicy nie pozwala
na jej analize przez kompilator i tym samym optymalizacje dostepu/uzyskania
do elementu, operacji na podtablicach itp.
Oczywiscie doceniam projekty typu Blitz++ i tym podobne oparte na wzorcach
ale.. no koncze bo znow sie zacznei dyskusja o wzorcach...

>: A jesli chodzi o referencje to i owszem.
>: Byloby to i lekarrstwo na szalenstwo wskaznikowe w C++
>: gdyby nie... No wlasnie
>: Gdyby nie to ze nie mozna zmienic obiektu "referowanego".
>: Moze mi ktos wytlumaczy dlaczego ?.
>
>Ech, co ja bede mowic... a moze by tak podejsc do tego z lekkim zrozumieniem,
>co ? W ogole nie czujecie jezyka C++. Dlaczego niby kojarzycie referencje ze
>wskaznikami ? To bez sensu. Referencje to zupelnie co innego. Referencje moga
>CZASEM BYC zaimplementowane przez wskazniki, ALE NIE MUSZA! Jezeli np. mamy w
>programie cos takiego:

A jak inaczej je zrealizowac ?
Referencja to nie alias (przezwisko) ale rzeczywista zmienna przeciez.

Dalej opuszczam bo mnie chodzilo wylaczne o uzasadnienie dlaczego jest dopuszczalne

int k;
int & rk = k;

a nie jest dopuszczalne.

int k;
int r;
int & rk;
...
rk  = k;
...
rk = r;

bardzo czesto stosuje np konstrukcje (i mam spokoj z miszaniem dostepu
przez operatory raz -> a raz . )

typ & zmienna = jakas_inna_zmienna;

ale nie moge np cos w rodzaju:

typ & zmienna;

if ( cos tam )
    zmienna = jakas_inna_zmienna;
else
    zmienna = jeszcze inna_zmienna;

Zanim zaczniesz rzucac pseudo kontrargumentami
przyjrzyj sie jak to jest zrealizowane chocby w Simuli.
Moze nabierzesz odpowiednego dystansu do
"super referencji" w C++.

Pozdrawiam
--
Adam Karpierz
Poszukuje stalej pracy, moje dane:
http://www.adares.alpha.pl/cv.htm