Aktív témák
-
QuarK
senior tag
Szerintem valamilyen win-es IDE-t kéne találnod hozzá; vagy egy ilyen általános szerkesztőt, ahol be tudod állítani, hol van a fordító, és milyen elven működik... A dosbox pedig a DOS-t emulálja, és nem a sebességéről híres
![;]](//cdn.rios.hu/dl/s/v1.gif)
''Másnál gond nélkül megy''... Nálad csak a BC++-t érinti, vagy midnen más DOS-os alkalmazásnál ezt produkálja? -
Zeck
aktív tag
Kért apró problémám van a Borland c++ 3.1-el.
Az eggyik, hogy futás közben az xp-s dosemulátor teljesen leterheli a procit, annyira, hogy pl, ha tálcán van a C++, akkor 2 perc alatt lépek be a sajátgépbe. Ha leveszem a prioritását taskmanagerben lowra, akkor már viszonylag használható mellette a rendszer, de nem az igazi így sem, és a szabad proci kapacitást így is elveszi.
A másik pedig, hogy ha grafikus programot futtatok C-ben áteszi 640*480-ba a képet és utána nem vált vissza, ha kilépek a programból. És ilyenkor a C kezelőfelülete is 640-ben marad teljesképernyőn (alapból ablakban fut), ráadásul a billenytyűzetet is elb***a, amíg ki nem lépek és vissza. -
Miracle
senior tag
-
Grag
csendes tag
Hi all!
Legnagyobb bánatomra a Borland C 3.11-el kell programozást tanulnom... eddig nem sok közöm volt a programozáshoz és ezek után se jósolok magamnak nagy jövőt mert nehéz!
) Első nagyon laikus kérdésem az, hogy el lehet-e indítani Xp-n és ha igen akkor hogy? előre is köszi a segítséget! -
Helló!
Az az igazság, hogy én azt mondom, hogy nem az igazi az ilyen gépen lévő könyv, nem lehet olyan jól használni (nem lehet elalvás előtt ágyban olvasgatni
). + az ingyenesek nem túl jók.
Szóval azt mondom, hogy ezt meg kell venni.
Én ANSI C-t tanulok. 2könyvet vettem eddig, amit párhuzamosan olvasok. ~4000FT volt a kettő.
Volt nálam kölcsönben egy C++-os könyv, az nagyon király:
Douglas Bell - Egyszerűbben Programozás C++ nyelveb
Teljesen az alapoktól. Nem tudom hol lehet kapni ('98-as kiadás).
Vannak komolyabb C++-os könyvek, azokban is van alap.
Itt érdemes körbenézni:
Bővebben: link
Ott van mindenféle nyelvhez könyv.
(Szerintem ha még nem tanultál C-t, érdemesenn avval kezdeni és jól elsajátítani a pointereket
Én ezeket vettem C-hez:
Bővebben: link
A híres Kerningham & Ritchie könyv 2. kiadása, alaposan de egy kicsit szárazan és nem mindig a leghasznosabb dolgokat mondja el.
Bővebben: link
Nagyon jól használható dolgokat mutat, van benne ANSI C, TURBO C, Grafika.)
[Szerkesztve] -
uzsz
senior tag
Mivel itt hozzáértő emberkék vannak én meg még csak szeretnék érteni hozzá, segítséget kérnék: Ha tud valaki linkeljen egy oldalt ahonnan le lehet tölteni C++ hoz való ''tananyagot'' Egészen az alapoktól kellene és magyarul. Annyit kerestem mint állat de nem igazán találtam offline is használható anyagot. Most ismerkednék a nyelvvel, de a könyv ami kéznél van az alap utasításoka, stb nem igazán taglalja, tehát túl magasról kezdi. Mi meg ülünk a gép elétt és nézünk ki a fejünkből ha egy mintaprogram nem működik.
Elére is köszönöm a segítséget. -
bdav
őstag
hi! ide irok, talán jo lesz itt is
sz'al az az én nagy bajom hogy volna nekem egy borland c++ 3.1 telepitöcucc. csak nem tudom használni. Windowsxp sp2, következö helyzzet: telepitö lfagy windowsbol inditva, dosbox 0.62-vel végigmegy, de hibát jelez (nemtom mér, anno format elött simán felment). sebaj, továbbmegy, a progi használható lenne, ha:
- dosboxbol, vagy winböl inditva a dosos progit (bc.exe) nem használhato egy csomo karakter, vagy nincs #-m, vagy )-m, vagy valami hiányzik mindig. ja magyar billkiosztás lenne.
- windowsos prog nem jo (bcw.exe), mostmár be se jön, azt irja h. ''divide by 0'' ezt egyböl inditáskor, elözöekben egy hello worldot nem tudtam rajta beüzemelni, azt irta h. nincs stdio.h.
a gond az h. jo lenne ebbe irnom a házimat egyetemre
illetve ansi c-ben. van még ms visual studio .netem de az kicsit bonyolult nekem (nem tudtam használni). ja meg van valahol egy turbo c-m is probálkozzak azzal? vagy tudtok valami jot (láttam elözö hszekben volt link vhova, de azt irtátok h. nincs debugger, pedig az jolenne ha lenne. leg1xübb a bc++ 3.1et lenne beüzemelni valahogy) -
#50
TheVeryGuest
senior tag
Szsolt
#49
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. -
#47
kisfurko
senior tag
TheVeryGuest
#45
válasz
TheVeryGuest
#45
üzenetére
Jaja... Bocsánat...
Ezért nem kaptam sosem ötöst... Papíron nem tudok programozni...
[Szerkesztve] -
#43
yerico
senior tag
TheVeryGuest
#41
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.
-
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... -
#41
TheVeryGuest
senior tag
yerico
#40
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] -
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. -
-
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... -
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. -
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? -
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
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. -
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. -
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... -
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... -
-
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.
-
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] -
#14
Szsolt
tag
_gerisoft_
#11
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] -
#13
_gerisoft_
tag
_gerisoft_
tag
^
-
#12
_gerisoft_
tag
_gerisoft_
tag
^
-
#11
_gerisoft_
tag
_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? -
#4
Szsolt
tag
_gerisoft_
#3
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] -
#3
_gerisoft_
tag
_gerisoft_
tag
help me, help me, help mííííííííííí!
-
#2
_gerisoft_
tag
_gerisoft_
tag
^
-
#1
_gerisoft_
tag
_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
![;]](http://cdn.rios.hu/dl/s/v1.gif)
) Első nagyon laikus kérdésem az, hogy el lehet-e indítani Xp-n és ha igen akkor hogy? előre is köszi a segítséget!
). + az ingyenesek nem túl jók.
)..
. de hogy lehet az, hogy sizeof(tomb)??
Aktív témák
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Kuponkunyeráló
- Új telefont és tabletet mutatott be a Telekom
- Milyen billentyűzetet vegyek?
- Milyen TV-t vegyek?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Melyik tápegységet vegyem?
- További aktív témák...
- HP 840 G3 Laptop 14" FHD/i5-6Gen/DDR4 8Gb/256GB SSD M2/Bluetooth/CAM 6hó Gari
- HP 840 G3 Laptop 14" HD/i5-6Gen/DDR4 16Gb/256GB SSD M2/Bluetooth/CAM 6hó Gari
- Dell 7390 Slim Laptop 13,3" FHD/i5-8Gen/DDR4 8Gb/256GB SSD M2/HDMI/BT/USB-C/CAM 6hó Gari
- Western Digital 3,5-es 3TB HDD-k
- Seagate Enterprise NAS HDD 3TB 7.2K 128MB SATA III 3.5''
- HIBÁTLAN iPhone 13 512GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3078, 100% Akkumulátor
- BESZÁMÍTÁS! Asus ROG STRIX Z490-G Gaming alaplap garanciával hibátlan működéssel
- DELL Universal Dock D6000 docking station (452-BCYH) (DisplayLink)
- Xiaomi Redmi 9AT 32GB, Kártyafüggetlen, 1 Év Garanciával
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
Állásajánlatok
Cég: FOTC
Város: Budapest