- Hamarosan bárki hazavihet egy Apple Vision Pro headsetet
- Gmail
- Az Intel a legmodernebb chipgyártó géppel előzheti meg az egész szektort
- DIGI kábel TV
- Anyagi katasztrófára figyelmezteti az Apple-t a brit média
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Információbiztonság, kiberbiztonság, adatvédelem
- Programozás topic
- Bittorrent topik
Aktív témák
-
_gerisoft_
tag
Képmegjelenítéshez létre kéne hoznom egy kb 640x480 méretű tömböt Borland C++ban (v3.1). De ezt a ebben a Borland C++ban az array parancsal nem lehet létrehozni, ugyanis sipákol a nagysága miatt. Nyilván nincs korlátozva a memóriahasználat..
..szóval hogy tudnék egy nagyobb tömböt létrehozni?
Geri''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
_gerisoft_
tag
^
''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
_gerisoft_
tag
help me, help me, help mííííííííííí!
''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
Szsolt
tag
válasz _gerisoft_ #3 üzenetére
Nem biztos, hogy tudok segíteni, de leírnád a kódot ahogy csináltad?
[Szerkesztve] -
_gerisoft_
tag
Ahol a változókat definilni kell, oda beírom, hogy array[640][480];, viszont így nem fut le, mert túl nagynak találja. Lényeg, hogy valahogy definiálni kéne egy nagyobb memória területet, amiben létrehozhatom a kívánt tömböt.
''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
Szsolt
tag
Én ansi C-ben így foglalnám le a mem-et:
int *t=(int*)calloc(307200,sizeof(int));
[Szerkesztve] -
atee07
tag
Bc++ 3.1-ben C és C++ progikat lehet írni,te gondolom,hogy C++ progit írsz,mert C-ben nincs array,legalábbis ANSI C-ben.De mivel a C++ a C-re épül,így kérdezem:abban nincs dinamikus memóriafoglalás?
''Egyszer annyira depressziós voltam,hogy le akartam ugrani a tizedikről.Hívtak egy papot,aki ennyit mondott:Elkészülni... Vigyázz...'' - Woody Allen
-
_gerisoft_
tag
Nos megint elakadtam.
Memóriát foglaltam le a következő képpen:
const MEMORYSIZE=307200; <-640x480-ból jön ki
typedef long ZBUFTYPE;
ZBUFTYPE *zbuffer;
zbuffer=(ZBUFTYPE *)farmalloc(MEMORYSIZE*sizeof(ZBUFTYPE));
Ezzel elvileg lefoglaltam egy memóriaterületet, ahogy egy 640x480-as felbontású képernyő minden pixeléhez hozzá tudok rendelni egy z-koordinátát. Ugye?
A következő panacssorral megpróbáltam feltölteni ezt a memóriaterületet, de nem sikerült:
for (c=0;c<MEMORYSIZE;c++)
zbuffer[c]=0;
Szóval az lenne a kérdésem, hogy hogy lehet jól hivatkozni a lefoglalt memóriaterületre?''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
_gerisoft_
tag
^
''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
_gerisoft_
tag
^
''Két dolog biztos: a halál és az adatvesztés. Szerinted most melyik volt?''
-
Szsolt
tag
válasz _gerisoft_ #11 üzenetére
Nem értem, mért kell külöm typedef a ZBUFTYPE-nak..
long int *tomb;
Farmalloc-ról még nem hallottam, csak mallocról, callocról es reallocról, úgyhogy nem tudom, hogy az jól van-e...
A for ciklussal semmi gond, kell működjön. de ha mégse, próbáld meg így:
for (i=0; i<MEMORYSIZE-1; ++i)
*(zbuffer+i)=0;
A MEMORYSIZE-1-ig kell menjen...szvsz
Összesítve,:
#include <stdlib.h>
int main()
{
long int * tomb=(long int*)calloc(307200,sizeof(long int));
long int i;
for (i=0; i<307199; ++i)
*(tomb+i)=0;
return 0;
}
[Szerkesztve]
[Szerkesztve]
[Szerkesztve]
[Szerkesztve]
[Szerkesztve] -
kisfurko
senior tag
A for hamisnál már nem fut le. Tehát i<SIZE a jó, nem i<SIZE-1.
Elég lesz a malloc is, úgy is kinullázza kézzel, nem?
Továbbá azt sem értem, miért nem lehet szegény main függvényt rendesen felírni...
int main(int argc, char *argv[])
Meg a tomb-nek is mennie kell.
Meg rendesen deklaráljuk a változókat, ha pedig C++, akkor meg miért nem tomb=new long [640][480].
[Szerkesztve] -
atee07
tag
A tomb egyébként megy,ahogy írtad,mert mindig lép a következő memóriacímre,és a *-al az ottani helyre írja be az értéket.A deklarácoió szerintem jó,ez egy sima mutatókból álló tömb,ahol a mutatók egy long int típusú adatra mutatnak.Ja ez ANSI C,nem C++,legalábbis az Szsolt által leírt.
''Egyszer annyira depressziós voltam,hogy le akartam ugrani a tizedikről.Hívtak egy papot,aki ennyit mondott:Elkészülni... Vigyázz...'' - Woody Allen
-
g@bo
nagyúr
ó hogy pont ezt tanulom.... de még nem értek hozzá. vajon miért..
-
kisfurko
senior tag
-
Szsolt
tag
Ebben eggyetértek Atee-val, mert az oké, hogy a tömbre mutat egy mutato:
az a *tomb, de mivel ez egy mutato, mely egy long decimal típus, műveletet végezhetünk vele. Ha hozzáadunk 1-et a tomb mutatóhoz, akkor a tomb[0] -ról a tomb[1]-re ugrik, és *(tomb+1)-el vagy tomb-vel hivatkozunk, arra a memóriacímre.
Javítsatok ki ha tévedek... -
bocs
csendes tag
ember, mit küzdesz itt 16 biten, amikor vannak ingyenes fordítók 32-re? ott semmilyen far, near stb problémád nincsen, az int változók is 32 bitesek, tehát 4 milliárdig mehetnek a 16 bites intek 64k-jával szemben.
a memóriamodellek is iszonyú kavarcok a régi 16 bites világban...
szóval használj valami újabb fordítót, pl ha borland, akkor van neki inegyes parancssoros fordítója 32 bites konzolos programokhoz...
vagy linuxon ott van az ingyenes kylix, ami 32 bites programokat, grafikus ablakozó alkalmazásokat enged csinálni, tökéletes debugger... mit kell szenvedni? tudom hogy szenvedés, nekem ezzel kellett dolgoznom vagy 5 évig...-bocs a hardwerláma-
-
kisfurko
senior tag
Tudom, hogy működnek a mutatók...
Ő azt írta, hogy:
''ez egy sima mutatókból álló tömb,ahol a mutatók egy long int típusú adatra mutatnak.''
Erre írtam, hogy nem. Az egész tömb long-ból áll, te meg oda mutatsz benne, ahova akarsz...
Semmi baj nem volt a
long int *tomb;
deklarációval, csak ő értette félre.
Meg felesleges *(tomb+j)-zni, amikor ez ekvivalens a tomb[j]-vel. Ha nem megy az utóbbi, akkor nem C fordító.
Egyébként annak ellenére, hogy műveletet lehet végezni a mutatóval, nem jelent semmit a méretére vagy ábrázolására nézve (gondolj a kiherélt 8086-os szegmentált címzésre). De ez csak kukacoskodás. -
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. -
Szsolt
tag
Legjobb tudámosam szerint nem kell megszorozni sizeof-al, nekem müködik úgy is.
A 2 dimenzós megoldás szebb, ebben eggyetértek, de bonyolultabb dinamikusan lefoglalni a tárterületet, meg 1-es C fordítók általában nem is szeretik az ilyen megoldást (pl.Dev-Cpp gcc fordító). Sokszor szívtam így, de miután átírtam 1 dim.-ba, már nem volt ''runtime error''.
A felszabadítással kapcsolatban meg tökéletesen igazad van..
[Szerkesztve]
[Szerkesztve] -
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? -
kisfurko
senior tag
Nem kell sizeof, mivel pont azért deklarálod a pointer típusát, hogy a fordító majd okosan tudja, mennyivel kell léptetni.
Szerintem is jobb itt a kétdimenziós tömb, viszont ha csak lineárisan lépkedsz, akkor javasolt az egydimenziós a sok overhead miatt (mindig feleslegesen kiszámolja a helyet, pedig sima léptetés elég lenne). Egyébként nyugodtan lehet a kétdimenziósat is egydimenziósként kezelni, ha kell.
Nem kell a dinamikus helyfoglalástól félni, egy komolyabb programban elengedhetetlen. A mutatóktól sem kell félni, gondolj a string-ekre, másként nem megy.
Persze tudom, hogy már C++, van string osztály (vagy mi), mégis érdemes az alapokkal tisztában lenni. -
kisfurko
senior tag
Nem értem, mi különbség van az egy vagy kétdimenziós tömb foglalása között.
tomb=(tipus *)malloc(meret*sizeof(tipus));
Mindkét esetben ez kell. Az, hogy egy [] vagy kettő van, az neked segít, de a tömb nem változik, az ugyanúgy egy egybefüggő memóriaterület lesz.
A malloc-nál pont azért kell a type override, mert mindenféle foglalásnál ugyanazt csinálja, lefoglal annyi egységet, amennyit a paraméterben megadtál. Azért szorozzuk be sizeof-fal, mert fingja nincs, mekkora egy tipusbeli elem.
Szerintem a set, get típusú dolgokat lehet elfelejteni... Majd esetleg OOP-ben. ZBuffer objektum... Fujjj... Libabőrös lettem... -
-
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. -
TheVeryGuest
senior tag
Ha így lenne a C++-ban lenne a világ legpazarlóbb memóriamenedzsere. Akárhánydimenziós tömb egy darabban foglalódik le. Mert így gazdaságos. Ha long matrix[480][640], akkor matrix[ i ] az valóban long [640] -re mutató pointer, de ez valójában egy sima long *-gal ekvivalens.
Ami érdekesebb a C szabványban, hogy pl.:
int vec[5] = { 1, 2, 3, 4, 5 };
esetén vec == i[vec] vagyis vec[0] = 0[vec]
A szabvány nem írja elő, hogy melyik oldalon áll az indexkifejezés és melyiken az indexelendő.
Na, csak sikerült kódrészlettel bekapcsolnom a dőlt betűt.
[Szerkesztve]“Perfection is attained not when there is nothing more to add, but when there is nothing more to remove” Antoine de Saint-Exupéry
-
kisfurko
senior tag
OK. Csupán azt felejtettem el, hogy honnan tudná szegény fordító, mekkora egy sor...
Egyébként lehet kétdimenziós tömböt mutató tömb nélkül is kezelni.
typedef long int ZBUFFER [640][480];
ZBUFFER *tomb;
tomb=(ZBUFFER *)malloc(sizeof(tomb));
Hivatkozni egy elemre a (*tomb)[x][y]-nal lehet.
Gusztustalan, ez van.
Ezért nem használok többdimenziós tömböt... Így is, úgy is ki kell számolni az indexet a memóriában... -
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.
-
kisfurko
senior tag
válasz TheVeryGuest #45 üzenetére
Jaja... Bocsánat...
Ezért nem kaptam sosem ötöst... Papíron nem tudok programozni...
[Szerkesztve] -
Szsolt
tag
Amúgy tud valaki, olyan URL-t, ahol le lehet tölteni a BorlandC++ 3.1-est.
(no credit card. ).. -
TheVeryGuest
senior tag
Hát a compiler free, de az IDE az nem valószínű, azóta is visszasírom a TurboVision-t. A 2.01-es IDEstül letölthető, de ebben nem tudom volt-e már C++, lehet, hogy csak C asse full ANSI.
http://www.thefreecountry.com/compilers/cpp.shtml
http://community.borland.com/article/0,1410,20841,00.html
Mondjuk ha valami jó kis texteditort használsz: CodeWright, UltraEdit, melléteszed a free compilert, oszt akkor már csak a debugger fog hiányozni.“Perfection is attained not when there is nothing more to add, but when there is nothing more to remove” Antoine de Saint-Exupéry
Aktív témák
- AKCIÓ! Szépségápolás, Haj - és Szakállápolási márkás gépek - BOLTI ÁR FELÉÉRT!
- Bomba! HP EliteBook 1040 G7 x360 Érintős Hajtogatós Ultrabook Tab 14" -70% i7-10710U 16/256 FHD LTE
- BONTATLAN Új Iphone 15 és 15 Plus 128-512GB 1év APPLE garancia gyári független Deák AZONNAL Átvehető
- BONTATLAN Új Iphone 13 128-512GB 1év hivatalos Apple garancia gyári független Deák Azonnal Átvehető.
- ÚJ BONTATLAN Apple Watch Series 8 S8 41-45mm Azonnal Átvehető DEÁK TÉRNÉL 1 Év Apple Garanciával.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs