OldComp.cz

Ahojte, mam taku malu otazocu na miestnych znalcov cecka.

Ako dynamicky vytvorit 2D pole ? Namiesto pevneho int pole[10],[20] chcem cosi ako int pole[X][Y] kde X,Y su premenne ktore budu zname az za behu programu. Na nete som nasiel vseliake navody, ale vsetky su zalozene na riadku pointerov ktore ukazuju na jednotlive stlpce pola. Ale toto ja nechcem, Ja potrebujem nejak nadeklarovat symbol pole tak aby ked urobim
tak budem moct pouzivat obvyklu konstrukciu pole[index1][index1] ktoru kompiler spravne pochopi a skompiluje ju ako priamy pristup do pola, t.j. v style riadok * dlzka_stlpca + stlpec a nechcem aby sa vykonavanie programu zbytocne zdrzovalo citanim pointerov ktore ukazuju na jednotlive stlpce pola.

A da sa to vobec ?

Jen od oka (muselo by se to prakticky vyzkoušet), co bude rychlejší: jedno čtení z pole indexů do pole prvků, nebo výpočet souřadnic ve dvourozměrné matici, převedené do lineární paměti?

_________________
Plesnivý sýr z Tesca, zatuchlé kuřecí řízky z Albertu, oslizlé hovězí a myší trus z Lidlu.
Nákup potravinářské inspekce v ČR, říjen 2023.

Program se "zbytecne" nezdrzuje zadnym ctenim pointru. Pointer je promenna, ktera ukazuje nekam do pameti. Pokud ti vadi to nasobeni, tak mi ver, ze vnitrne se stejne nasobeni nevyhnes. Proste radek je jeho 'cislo * delka + sloupec'. Zapisem pole[x][y] rikas to same, jen to nevidis. A jeste, pokud je pole dynamicke, tak kompilator nemuze vedet, kde je konec radku, potazmo celeho pole. To si musis pohlidat.
Zkus tohle:
https://www.geeksforgeeks.org/dynamically-allocate-2d-array-c/
a nezapomen na:

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr

Jednoznacne rychlejsi bude vypocet suradnic v matici na linearnu adresu. Kedze cely vypocet sa urobi v ramci procesora, je hotovy prakticky okamzite, kdezto citanie z pola pointerov je jeden pristup do pameti navyse, a to vzdy velmi zdrzuje.

No, takto. Bud si si moj dotaz poriadne neprecital, alebo mozno som to iba ja nenapisal dost zretelne. Takze skusim byt viac nazorny a konkretny.
Nasobenie ktore si tam kompiler vlozi sam, mi praveze vobec nevadi ! A okrem toho, ako som uz vyssie napisal, je to iba interna operacia v praci procesora, a ta je hotova velmi rychlo, vobec nezdrzuje.
Presne toto chcem, aby kompiler interne robil, ked ja napisem pole[x][y].
Ved prave to je "gro" mojej otazky. Ako kompiler prinutit vygenerovat taky kod, aby velkost riadku nebral ako vopred znamu konstantu, ale ako premenlivu hodnotu, a nasobenie, ktore sa interne vykonava pri pouziti pole[x][y], robil nie s konstantou, ale s touto premennou.
A toto prave nechcem ! Ked sa poriadne pozries na vsetky tie priklady, tak je to bud o tom, ze ty ako programator musis "rucne" robit to nasobenie *(arr + i*c + j) = ..., alebo v pripade ak chces priamo pouzivat obvyklu konstrukciu pole[x][y] tak zase potrebujes este pridavne pole pointrov a pristup ku kazdemu prvku pola potrebuje dva pristupy do pameti.
Lenze ja kvoli prehladnosti vyslovene chcem pouzivat tento obvykly klasicky zapis pole[x][y] ale dvojity pristup do pameti je pre mna z dovodov efektivity jednoducho neakceptovatelny.
Tak na toto nastastie kludne zabudnut mozem, pretoze pri ukonceni procesu sa vsetka jeho pamet aj tak uvolni defaultne a akekolvek *free* je tu uplne zbytocne

co tak:

Ak by to slo takto:
potom by to bolo riesenim. Ale takuto syntax v #define kompilery obvykle nepodporuju...

To ti vadi ty hranate zavorky? Tak to ti asi neni rady.

on to prece dela ten program za chodu. Kompilator o tom ve sve dobe nema ani potuchy (A tvoje ruce taky ne, aby jsi to delal rucne). To nasobeni prece dela procesor uvnitr nebo... asi jsem nejaky unaveny a nechapu to. Pardon.

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr

Nemuzes misto pole pointeru alokovat pointer na pole, ktere ma rozmer tebou nactene cislo Y? Neco v tomto duchu:



Vystup programu pak muze byt napr.:

na moje pocudovanie, netreba ani malloc:



otazka ale je, ako to je prenositelne medzi roznymi kompilermi...

Tak jasne, kdyz to nechces dynamicky alokovane, tak muzes pouzit staticke dvourozmerne pole (s promennou delkou).



IMHO jakykoliv slusny prekladac, co umi C99, ktere pridalo variable-length arrays. Ted jeste koukam, ze C11 VLA nemusi podporaovat, kdyz definuji makro __STDC_NO_VLA__.

tohle je sice c++, ale kdyz nahradis new za malloc a poresis delete na konci, tak mas dynamicky alokovanou matici matice[ROW][COL]



nebo totez zapsano jinak:

To je pole pointerů, kterému se chtěl Busy vyhnout. Chce lineární pole, kde se offset prvku počítá jednoduchým násobením. K čemuž má nejblíž buď #define POLE(x,y) v C, nebo přetížení operátoru [] v C++ ( int* & Matrix::operator [](const int &index) const { return &mat[index * cols]; } ... tedy jedno lineární pole alokované s malloc, operátor [] vrací adresy řádků které spočítá násobením, druhý [] přičte sloupec ).

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Ano, asi to tak bude
Pretoze ja som predtym napisal:

To vyzera zaujimavo, ale nedari sa mi to rozbehat:
Nemal by to byt iba warning ? To sa mi nejak nezda. Co vlastne realne vadi tomu kompileru ? Nedari sa mi najst vhodne pretypovanie aby mi to zozral.

Presne tak !
Toto riesenie sa mi vidi zatial najlepsie. Mohol by si mi prosim uviest nejaky konkretny priklad typu tych vyssie uvedenych (co rovno skompilujem) ? S pretazovanim hranatych zatvoriek nemam vela skusenosti, a tie co mam, koncia u toho klasickeho znameho skolskeho prikladu na pretazene + - * / ktore pocitaju kompexne cisla...