Hirdetés
- Kétszáznál is több játékhoz hozta el az FSR Redstone-t az új AMD Software
- Több száz játékban kezdi meg karrierjét az FSR Redstone
- Thermalright tulajok topikja
- iPad topik
- Külső merevlemezek - USB, eSATA, FireWire HDD
- Rogyásig pakolható a Cooler Master Cosmos szériás csúcsháza
- TCL LCD és LED TV-k
- Azonnali alaplapos kérdések órája
- Milyen videókártyát?
- Hamarosan "kémkedhet" az NVIDIA a saját GPU-i után?
Új hozzászólás Aktív témák
-
Karma
félisten
válasz
Sk8erPeter
#1412
üzenetére
"A double *ujtomb; sorban tehát deklarálunk egy pointerváltozót ujtomb néven, aminek csak később foglaljuk le a szükséges memóriát, először még csak meghatározzuk, hogy "lesz ilyen"."
Igen. Bár ha nagyon szőrözni akarnék, ahogy egyszer már tettem, a megfogalmazás nem tökéletes: magát a pointert sikeresen definiáltuk, 4 byte-ot kapott a stacken (vagy globálisan), mint egy átlagos változó. De ezt most felejtsük el egy pillanatra, mert irreleváns.
"Amikor megtudtuk az eredeti tömb számunkra szükséges elemeit megszámolva, mekkora új tömbre van szükségünk, azután lefoglaltuk neki a számára szükséges memóriát. Ezután tömbként és egyben pointerként használtuk fel a későbbiekben, rakosgattunk bele elemeket, és itt ez most kicsit zavaros számomra, hogy akkor most melyik fogalmat is használjuk, ami helytálló. Mert tömbnek foglalunk helyet, de pointertömb...
"Nem, mi csak és kizárólag pointerként használtuk, nincs külön olyan, hogy "tömbként" használni. Ez a szép a C-ben (konkrét és ironikus értelemben is), hogy ilyen egyszerű
Mint írtam korábban, a p[n] subscript operátor az ekvivalens a *(p+n) művelettel.A pointertömb egy teljesen más fogalom. Pl. int **valami; egy int pointerre mutató pointer, amivel (hasonlóan a második példakódhoz) tömbök tömbjét lehet megvalósítani. Ugyanezt lehet fix méretben is: int valami[5][2];.
"Ráadásul - bocsi az értetlenkedésért, csak vannak ilyen homályos pontok - akkor a memóriafoglalással ezek szerint nem "méretezünk", hanem nem tudom, mit csinálunk
"A memóriafoglalással memóriát foglalunk

"És még egy pluszkérdés: a main()-ben free-vel felszabadítjuk a memóriát, de ekkor nem "szabadulunk meg" egyben az adatszerkezet már korábban eltárolt értékeitől is?"
Dehogynem. Amire meghívod a free-t, az felszabadul, az értékei érvénytelenné és elérhetetlenné válnak. (Legalábbis így kell bánni vele, ha nem akarsz bugzani.)
Fontos megjegyezni, hogy egy dinamikus pointertömbnél az alstruktúrákat egyesével fel kell szabadítani, a fordító nem fogja kibogozni!
-
shev7
veterán
válasz
Sk8erPeter
#1412
üzenetére
bar nem nekem szol a kerdes probalok valaszolni, ha mar itt vagyok:
"A double *ujtomb; sorban tehát deklarálunk egy pointerváltozót ujtomb néven, aminek csak később foglaljuk le a szükséges memóriát, először még csak meghatározzuk, hogy "lesz ilyen"."
Lenyegeben igen.
Amikor megtudtuk az eredeti tömb számunkra szükséges elemeit megszámolva, mekkora új tömbre van szükségünk, azután lefoglaltuk neki a számára szükséges memóriát.
Inkabb nevezzuk memoriateruletnek, de igen.
Ezután tömbként és egyben pointerként használtuk fel a későbbiekben, rakosgattunk bele elemeket, és itt ez most kicsit zavaros számomra, hogy akkor most melyik fogalmat is használjuk, ami helytálló. Mert tömbnek foglalunk helyet, de pointertömb...
Na itt kezdodik a fogalomzavar. Eloszor is ne hivd pointertombnek mert az nem az. A pointertom az szamomra a pointerek tombjet jelenti, es itt nem errol van szo. Hogy mi is tortenik ahhoz egy kis magyarazat.
Vegyunk eloszor egy egyszeru byte pointert: byte *p;
a p valtozo tartalma egy memoria cim. A *p ahogy a deklaraciobol is olvashato egy byteot jelent (vagyis a p pointer altal mutatott erteket). Ha tovabbmegyunk a *(p+1) - a p memoriaterulet utani byte-on levo byte-ot jelenti. Na es most jon a turpissag, maradjatok meg velem
hogy ne legyen olyan bonyolult az elet, behoztak ezt a tomb pointer megfeleltetest. (illetve nem behoztak, eddig is igy mukodott, csak mivel korabban nem voltak pointerek, nem foglalkoztunk a problemaval) Azaz a p[5] az megegyezik azzal mintha azt irnad hogy *(p+5).de ugye ez csak byteoknal mukodne ilyen egyszeuen. Int-nel mar bonyolultabb a tema. Ott a kovetkezo egyenloseg igaz: p[5] = *(p+sizeof(int)*5)
Namost mivel ez alapbol igy mukodott tomboknel, ( ha deklaralsz egy olyat hogy
int tomb[100]; akkor a tomb igy magaban egy pointer, es a hatterben pont egy ilyen konverzio zajlik le) akkor a pointerek bevezetesevel csak annyi tortent, hogy ez "mukodik a masik iranyba is"MOD: ja es ezert indexeljuk 0-tol a tomboket C-ben

Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Kétszáznál is több játékhoz hozta el az FSR Redstone-t az új AMD Software
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Több száz játékban kezdi meg karrierjét az FSR Redstone
- Elemlámpa, zseblámpa
- TGA2025 - Lara Croft felbukkanása már szinte borítékolt
- Diablo IV
- Vivo X300 - kicsiben jobban megéri
- A részvénypiacot is kilőné az űrbe a SpaceX
- Thermalright tulajok topikja
- iPad topik
- További aktív témák...
- Xiaomi 13T Magánszemélytől Garanciával
- ASUS ROG PG39WCDM Ívelt Gamer Oled Monitor!39"/2k ultrawide/240hz/0,03ms/Gsync-Freesync/Type-C/!
- Akciós! Makulátlan MacBook Pro 16" i9 16GB 1TB 5500M asztro szürke részletek a leírásban.
- UF Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -50% i7-1360P 16/1TB Iris Xe 2,8K OLED 90Hz
- iPhone 13 Pro Max 256GB Graphite megkímélt állapotban eladó!
- Das Keyboard Prime 13 /Cherry MX Brown/EN/Fehér háttér világítás/
- Samsung Galaxy S25 256GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max/
- Lenovo LOQ 15IRH8 - 15.6"FHD IPS 144Hz - i5-12450H - 16GB - 512GB - RTX 4050 - Win11 PRO - 1 év gari
- BESZÁMÍTÁS! Gigabyte B650M R5 7600X 32GB DDR5 512GB SSD RX 6900XT 16GB Zalman Z1 PLUS NZXT 850W
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
"
Mint írtam korábban, a p[n] subscript operátor az ekvivalens a *(p+n) művelettel.
"


