[elektro] többdimenziós struktúra c++
Info
info at kiralyelektronika.hu
Tue Jun 4 13:12:33 CEST 2013
Igen. Már a megoldáson túl vagyunk, hogy típusdefinícióra lenne
szükség, de nem eszi meg az ő C-je. Esetleg ha megmondaná a nyelvet,
lehet haladnánk is.
Pl. amit én használok, bekapcsolom az 'Extended syntax'-ot, és elég
vad dolgokat meg tudok etetni vele :) Ezért nem értem miért nem lett
még megoldva. Az irány adott, a hiba megvan...az ezköz ismeretlen.
> Hi!
> Sztem túlértelmezed, minden mérete ismert a tömbnek.
> Üdv
> 2013. június 4. 13:00 SZIGETI Szabolcs írta, <szigiszabolcs at gmail.com>:
>> Hali!
>> Nem a méret ismertségével vagy nem ismertségével van baj. hanem azzal, hogy
>> többdimenziós tömböt csak úgy tudsz függvénynek átadni, ha az utolsó
>> dimenzió kivételével a többi a fordítási időben ismert és konstans.
>> Legalább is, ha jól értem ezzel küzdesz. Vagyis csak olyan függvényt tudsz
>> mondjuk csinálni, ami 5-ször x méretű tömböt tud kezelni. Olyat nem, ami
>> y-szor x méretűt.
>> Szabolcs
>> 2013. június 4. 12:43 Balla Zoltán írta, <sdrlab at yandex.ru>:
>> > Feladó: "SZIGETI Szabolcs" <szigiszabolcs at gmail.com>
>> > >De tudsz. Csak neked kell bizonyos adatokat kezelned. A C-ben nem
>> létezik
>> > >tömb. Az index operátor csak egy kényelmesebb írási módja a pointerekkel
>> > >való szorzásnak és összeadásnak. Már volt róla szó, de itt a példa:
>> > >
>> > >int t[5];
>> > >
>> > >mivel t önmagában az első (nulladik elem) címét jelenti, azaz ugyanaz
>> mint
>> > >&t[0] ezért mondjuk t[3] írható úgy is, hogy *(t+3). Hiszen a 3. elem a
>> > >memóriában pont 3 int-nyi távolságra van a 0. elemtől. A fordító tudja,
>> > >hogy *t int méretű, tehát a 3-at magától beszorozza sizeof (int)-tel.
>> > >Viszont ha t[3] ugyanaz, mint *(t+3), akkor értelemszerűen ez ugyanaz,
>> > mint
>> > >*(3+t), hiszen az összeadás kommutatív. Viszont akkor az első lépést
>> > >fordítva alkalmazva, arra kell, hogy jussunk, hogy ez ugyanaz, mint
>> 3[t].
>> > >Ami hülyén néz ki, de eddig minden C fordító megette, ami azt
>> bizonyítja,
>> > >hogy valóban nincsenek tömbök, csak pointerek.
>> > >
>> > >Ez viszont azt jelenti, hogy a fordító általában (ez alól van egy kis
>> > >kivétel, de nem befolyásolja a mostani kérdést) nem tud a tömb
>> méretéről,
>> > ő
>> > >csak egy pointert kezel. Vagyis, ha tömböket akarsz átadni pl.
>> > függvénynek,
>> > >akkor külön kell arról gondoskodnod, hogy a méretet átadjad.
>> > >
>> > >Ha két dimenziós tömbbel foglalkozol, az valójában egy egydimenziós
>> tömb a
>> > >memóriában, sorfolytonosan tárolva. Ezért ha ezt adod át függvénynek, az
>> > >egyik dimenziót fixre kell venni, hogy a compiler ki tudja számolni,
>> hogy
>> > >hol vannak a sorok. Jobban jársz ilyenkor, ha csinálsz egy tömböt, ami a
>> > >többi tömböt tárolja, mert akkor akármilyen méretet tudsz kezelni,
>> nyilván
>> > >itt is neked kell a méreteket tárolni, és átadni.
>> > >
>> > >Ha ez nem tetszik, akkor válassz olyan nyelvet, amiben valódi tömbök
>> > vannak
>> > >(tehát a compiler tárolja a méretét, és ellenőrzi a túlcímzést.)
>> > >
>> > Nem egészen érted a kérdésem....
>> > Én most nem dinamikus, ismeretlen méretű kétdimenziós struktúrát akarok
>> > kezelni.... A struktúra
>> > adott, a dimenziója szintén, a méretét is tudom. Át tudom adni
>> > futásidőben...de ha ez nem megy,
>> > akkor a fix is megteszi! Tehát egy ilyen adatszerkezetet szeretnék
>> > generálni a fogadó oldalon, a
>> > függvényen belül, mert nekem most a kétdimenziójú indexelés lenne
>> > célszerű, mivel így is kell
>> > variálni az indexekkel rendesen, nem szeretném ezt egy egydimenziójú
>> > tömbön kínlódva megcsinálni!
>> > Jelenleg a cimre hivatkozva az általad is följebb jelzett
>> > mutatóaritmetikával hivatkozok az
>> > egydimenziós(nak megfelelő) tömb elemeire, és azon belül a struktúra
>> > tagjaira. Ez így megy, de nincs
>> > két dimenziót kezelő indexelésem sem...és ronda a kód, mint az atomháború
>> > )) Ez így nem járható út
>> > nekem... mindenképpen kétdimenziós, indexes elérés kellene....
>> >
>> > Zoli
>> >
>> > -----------------------------------------
>> > elektro[-flame|-etc]
>> >
>> -----------------------------------------
>> elektro[-flame|-etc]
> -----------------------------------------
> elektro[-flame|-etc]
More information about the Elektro
mailing list