Aktív témák
-
yerico
senior tag
válasz
TheVeryGuest
#41
üzenetére
Nem olvastad el, hogy azt írtam, nem egy menetben foglalod a tömtöt, hanem 2 menetben, a 480 eleműeket egyesével, és a 640 eleműt is külön, így a 640 eleműd csak pointereket fog tartalmazni.
-
yerico
senior tag
A kétdimenziós tömbnél ugyebár pointerekre mutató pointertömböd lesz , azaz foglalsz 640 db 480 elemű longra mutató pointernek helyet. Ennek az elemeit már **-gal éred el, és nem sima *-ként. A sima esetben lesz egy 640*480 longot tartalmazó tömbre egy pointered, a 2D esetben egy 640 elemű long pointert tartalmazó tömbre mutató pointered.
Jelen esetben a long és a pointer mind 4 byte-on tárolódik (pointer = long ugyebár), ezért itt megegyezik, de nem feltétlenül fog megegyezni char esetén pl.
Apropó, ez ilyenkor feltételezi, hogy a 480 elemű tömböknek egyesével foglalsz helyet. -
-
yerico
senior tag
Ha egydimenziósan foglalod, akkor meg csinálni kell egy függvényt, ami az x, y koordinátákat átalakítja, és a tömböt tomb[x*640 + y]-ként címzi, és visszaadja az értéket. Ha csinálsz erre egy set és egy get függvényt is, akkor máris tudod 2D-sént kezelni.
A sizeoffal való szorzás gyanús, de a pointer + érték az annyi bájttal nagyobb címet adna vissza tudtommal, de rémlik, hogy nem így használtam, mikor anno írtam egy ilyet egy PGSM példaprogramba, hanem tényleg a következő értékre ugrott.
Apropó, miért kell itt long tömbnek lennie, miért nem jó egy sima short int, esetleg egy char? -
yerico
senior tag
Most lehet, hogy hülyeséget írok, de a *(tomb + j) esetében, mikor a tömb egy long tömb, akkor a tomb+j helyett nem kellene tomb + j*sizeof(long) véletlenül, mivel a long az 4 byte-on tárolódik, így egy 640* 480-as long tömb az 640 * 480 *4 byte nagyságú lesz. Egyébként meg érdemesebb dupla forciklusban tomb[j]-ként használni, mert sokkal jobban átlátható, felesleges egydimenziós tömbként használni. A mutatós címzést nem szoktam használni, áttekinthetetlenné teszi a kódot, pár magasabb szintű kódolási tudásról árulkodik

Persze ekkora tömb már lehet, hogy nem fér a stackbe, ezért kell a dinamikus memóriafoglalás, viszont akkor fel is kell majd a végén szabadítani.
Aktív témák
- Kormányok / autós szimulátorok topikja
- BMW topik
- Anglia - élmények, tapasztalatok
- MWC 2026: Bajnoki címre pályázik a Xiaomi Watch 5
- Okos otthon - Home Assistant, openHAB és más nyílt rendszerek
- Parkside szerszám kibeszélő
- Építő/felújító topik
- Az Intel szerint mindenkit érint, illetve érinteni fog a CPU-hiány
- Gitáros topic
- OLED TV topic
- További aktív témák...
- LG 27GX704A-B - 27" OLED evo / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- LG 27G640A-B - 27" IPS / QHD 2K / 300Hz & 1ms / NVIDIA G-Sync / FreeSync / DisplayHDR 400
- Xbox One S All Digital eladó!
- Apple iPhone 11 / 128GB / Kártyafüggetlen / 12Hó Garancia / Akku:100%
- Apple iPhone 11 Pro / 64GB / Kártyafüggetlen / 12HÓ Garancia / Akku: 90%
- Dell Latitude 5510 - 15.6" FHD IPS - i5-10210U - 16GB - 512GB SSD - Win11 PRO + Office
- BESZÁMÍTÁS! 2TB Samsung 980 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- -75% Dell XPS 13 (9320) i7-1260P 16GB Ram/1TB SSD FHD+ Gari
- HIBÁTLAN iPhone 15 128GB Pink-1 ÉV GARANCIA - Kártyafüggetlen, MS4635
- Vállalom Xiaomi Okoskamerák szoftveres javíttását
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Rengeteg char** pointerezés, meg dinamikus tömbök garmadája... az OOP ezek után megváltás.
