Szasztok!
Hogyan tudok bináris fájból struktúrát visszaolvasni?
(Borland C) ezt a tanuljuk a suliban. Bár inkább ANSI C-znék.
MysteryKe.
Hozzászólások
fread? ha szerencsed van egyben. de erdemes egyesevel kiirni/visszaolvasni a tagokat, mert ha van pl. valami struct member alignment, akkor a padding is kiirodik, igy csak ugyanolyan beallitasokkal olvashato vissza.
nem sizeof struct-nyit kéne olvasni? és azt egy struktúrába tömni? ha szöveg is van benne, akkor meg a struktúra elemek sizeof-jányi olvasol, és elemen ként töltöd fel, de ha szöveg volt, akkor '\0' -is olvasod a szöveget. padding-el szerintem nem lehet baj, ha nem használtál bitmezőket, de ezt valki architektúra szekértőtől kéne kérdezni...illetve a használt típusoktól is biztos függ, meg szóhossztól, meg a procitól, meg a c fordítótól :) illetve úgyis kiderül :)
írj mintaprogit, ami kiír fileba, és próbáld másikkel beolvasni. ha megy, próbáld bonyibb struktúrával, és ha úgy is megy, öröm van.
---
Reactor error - core dumped!
Alapszabály hogy struktúrát nem írunk / olvasunk közvetlenül fájlba / fájlból. Keress vagy írj valami absztrakciót ami architektúra- és fordítófüggetlenül ábrázolja a struktúrádat (pl ASN.1 pont erre való).
Alapszabály hogy struktúrát nem írunk / olvasunk közvetlenül fájlba / fájlból
Attol fugg mire kell. Ha csak tmpfile-okat gya'rt, valamilyen okna'l fogva (pl nagymennyisegu adat feldolgozasahoz), akkor teljesen jo, ha a struct-okat sizeof(struct...) me'retben kiirja.
Arch/ford fuggetlen esetben persze az mas. Koztes megoldaskent lehet ilyesmiket csinalni hogy tiszta'n [u]int{8,16,32,64}_t tipusokbol teszed ossze a doglot, sok es ezeket kiiratas elott / visszaolvasas utan egy hton/ntoh fuggvenyen keresztul atfolyatod az adatodat.
A lényeg az volt, hogy legyen egy menüvezérelt program.
Ez ok.
LEgyen egy menüpontja, ami először bekér egy fájl elérési útját és létrehozza a fájlt,
majd bekér struktúrába nevet, árat és darabszámot. Majd ezt mentse el a fájlba.
Egy másik menüpontba, meg kérje be a létrehozott fájl elérési útját és
listázza ki a struktúrát.
Tud valaki olyan könyvet, amely szájbarágósan elmagyarázza az ANSI C-t?
Linux alá is szeretnék programozni. De a suliban a Borland C(++)-t használjuk, melynek saját headerjei vannak, meg függvényei. Vagy létezik linux alá "Borland C(++)-klón"?
(Azért rakom zárójelbe a ++-t, mert mi még csak sima C-ben programozunk C++ fejlesztőkörnyezetben.)
A Kerigan & Richie konyv szerintem jo.
Ha a bc++ klon alatt IDE-t ertesz, van sok. De kisebb programokhoz, hazikhoz siman eleg pl.: (mcedit; kate; vim) , gcc. Legalabbis ha nem nagy es bonyorult a projekt, akkor ezeket hasznalom. Irsz hozzajuk egy Makefile-t es akkor aztan mar semmi panaszod nem lehet a forditasra sem.
Csak a -Wall parametert ne hagyd ki ;)
Nem az IDE-t értem alatta.
Hanem, ami tartalmazza a header fájlokat és tudja a borlandc++ saját függvényeit is.
Tudom, hogy áthúzhatom a header fájlokat a bc++-ból, de mi sűrűn használjuk a conio.h-t,
ami úgytudom, hogy kifejezetten DOS specifikus.
Tehát azért kérdezem, hogy léteik-e ilyen fordító(vagy ha van benne IDE az még jobb), ami teljesen ugyanúgy működik-e mint a bc++. Tehát ha használom a conio.h-t, akkor a clrscr() függvényre ugyanúgy működjön, linux alatt, mint DOS alatt.
Ha bináris fájlokat kezelsz, akkor adott platformon (i386)
semmilyen visszaolvasási gondod nem lehet.
1.
Probléma abból lehet, hogy ha egy adott compiler beállítás
mellett elkészült progival kiírsz valamit, majd egy más compiler
beállítás mellet (akár ugyanazon forráskódból) fordított programmal akarod visszaolvasni.
2.
Másik lehetőség, hogy más platformon újrafordítod a programodat és az előző platformon futó
program ott kiírt outputját próbálod visszaolvasni.
Az első verzió akkor léphet fel, ha az ősidőkben használatos
memóriamodell beállításokat változtatod a compilernél, vagy, ha az alapértelmezett
struktúra pakolási módot változtatod. Minden fordító a struktúrák helyfoglalása során
próbál optimálisan memóriát kezelni, azaz a platform processzor szintű adatmozgatási
utasításaiban használt regiszter szélességre, vagy ennek többszöröseire illeszteni a struktúra elemek határait. Teszi ezt azért, hogy egyszerűbb, gyorsabb lehessen a kód utása.
Elég könnyen kideríthető, hogy az adott compiler milyen trükközést csinál éppen az adott platformon.
Fogod az alaptípusokat és sizeof()-fal megnézed, hogy milyen hosszúak byte-ban mérve.
Érdekességeket a char, meg int tipusoknál lehet találni leginkább. A char-ral létrehozott tömb például akármilyen hosszal bírhat. Struktúrán belül használt char nagy valószínűséggel a definiált méreténél fizikailag nagyobb helyet foglal majd, ha egzotikus hosszal definiálod (pl.:3, 15, 61 stb). Másik az int, mert az meg platform függő, hogy milyen széles.
A másik visszaolvasási probléma meg a little/big endian miatt van. Az Intel és a Motorola
processzorok alaptípus ábárzolása például eltérő byte sorrendű. Pl egy 32 bites int 4 byte-ja, nem ugyanazt az értéket jelenti. Fel kell cserélni az adott platformon a más platformon binárisan kiírt 4 byte 2-2 byte-ját, hogy ugyanazt az int értéket kapjuk.
Egyébként az ilyen trükkös platform független bináris állományok kezelésénél jó szolgálatot tesznek a unionok.
Üdv,
t
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)
Hozzászólások
fread? ha szerencsed van egyben. de erdemes egyesevel kiirni/visszaolvasni a tagokat, mert ha van pl. valami struct member alignment, akkor a padding is kiirodik, igy csak ugyanolyan beallitasokkal olvashato vissza.
Vágom, hogy az fread-el kell, de hogyan szedem szét tagokra meg ilyenek?
nem sizeof struct-nyit kéne olvasni? és azt egy struktúrába tömni? ha szöveg is van benne, akkor meg a struktúra elemek sizeof-jányi olvasol, és elemen ként töltöd fel, de ha szöveg volt, akkor '\0' -is olvasod a szöveget. padding-el szerintem nem lehet baj, ha nem használtál bitmezőket, de ezt valki architektúra szekértőtől kéne kérdezni...illetve a használt típusoktól is biztos függ, meg szóhossztól, meg a procitól, meg a c fordítótól :) illetve úgyis kiderül :)
írj mintaprogit, ami kiír fileba, és próbáld másikkel beolvasni. ha megy, próbáld bonyibb struktúrával, és ha úgy is megy, öröm van.
---
Reactor error - core dumped!
Alapszabály hogy struktúrát nem írunk / olvasunk közvetlenül fájlba / fájlból. Keress vagy írj valami absztrakciót ami architektúra- és fordítófüggetlenül ábrázolja a struktúrádat (pl ASN.1 pont erre való).
Alapszabály hogy struktúrát nem írunk / olvasunk közvetlenül fájlba / fájlból
Attol fugg mire kell. Ha csak tmpfile-okat gya'rt, valamilyen okna'l fogva (pl nagymennyisegu adat feldolgozasahoz), akkor teljesen jo, ha a struct-okat sizeof(struct...) me'retben kiirja.
Arch/ford fuggetlen esetben persze az mas. Koztes megoldaskent lehet ilyesmiket csinalni hogy tiszta'n [u]int{8,16,32,64}_t tipusokbol teszed ossze a doglot, sok es ezeket kiiratas elott / visszaolvasas utan egy hton/ntoh fuggvenyen keresztul atfolyatod az adatodat.
Nyilvan nem cel az iskolaban, hogy ilyen szempontbol jo legyen a megoldas, a lenyeg a binaris file. Gondolom...
mmap()
hűű.. ez jó eszemb sem jutott... de ez viszon tényleg architektúrafüggő!
---
Reactor error - core dumped!
A lényeg az volt, hogy legyen egy menüvezérelt program.
Ez ok.
LEgyen egy menüpontja, ami először bekér egy fájl elérési útját és létrehozza a fájlt,
majd bekér struktúrába nevet, árat és darabszámot. Majd ezt mentse el a fájlba.
Egy másik menüpontba, meg kérje be a létrehozott fájl elérési útját és
listázza ki a struktúrát.
Ennyi.
Tud valaki olyan könyvet, amely szájbarágósan elmagyarázza az ANSI C-t?
Linux alá is szeretnék programozni. De a suliban a Borland C(++)-t használjuk, melynek saját headerjei vannak, meg függvényei. Vagy létezik linux alá "Borland C(++)-klón"?
(Azért rakom zárójelbe a ++-t, mert mi még csak sima C-ben programozunk C++ fejlesztőkörnyezetben.)
A Kerigan & Richie konyv szerintem jo.
Ha a bc++ klon alatt IDE-t ertesz, van sok. De kisebb programokhoz, hazikhoz siman eleg pl.: (mcedit; kate; vim) , gcc. Legalabbis ha nem nagy es bonyorult a projekt, akkor ezeket hasznalom. Irsz hozzajuk egy Makefile-t es akkor aztan mar semmi panaszod nem lehet a forditasra sem.
Csak a -Wall parametert ne hagyd ki ;)
Nem az IDE-t értem alatta.
Hanem, ami tartalmazza a header fájlokat és tudja a borlandc++ saját függvényeit is.
Tudom, hogy áthúzhatom a header fájlokat a bc++-ból, de mi sűrűn használjuk a conio.h-t,
ami úgytudom, hogy kifejezetten DOS specifikus.
Tehát azért kérdezem, hogy léteik-e ilyen fordító(vagy ha van benne IDE az még jobb), ami teljesen ugyanúgy működik-e mint a bc++. Tehát ha használom a conio.h-t, akkor a clrscr() függvényre ugyanúgy működjön, linux alatt, mint DOS alatt.
fwrite()/fread() páros.
Ha bináris fájlokat kezelsz, akkor adott platformon (i386)
semmilyen visszaolvasási gondod nem lehet.
1.
Probléma abból lehet, hogy ha egy adott compiler beállítás
mellett elkészült progival kiírsz valamit, majd egy más compiler
beállítás mellet (akár ugyanazon forráskódból) fordított programmal akarod visszaolvasni.
2.
Másik lehetőség, hogy más platformon újrafordítod a programodat és az előző platformon futó
program ott kiírt outputját próbálod visszaolvasni.
Az első verzió akkor léphet fel, ha az ősidőkben használatos
memóriamodell beállításokat változtatod a compilernél, vagy, ha az alapértelmezett
struktúra pakolási módot változtatod. Minden fordító a struktúrák helyfoglalása során
próbál optimálisan memóriát kezelni, azaz a platform processzor szintű adatmozgatási
utasításaiban használt regiszter szélességre, vagy ennek többszöröseire illeszteni a struktúra elemek határait. Teszi ezt azért, hogy egyszerűbb, gyorsabb lehessen a kód utása.
Elég könnyen kideríthető, hogy az adott compiler milyen trükközést csinál éppen az adott platformon.
Fogod az alaptípusokat és sizeof()-fal megnézed, hogy milyen hosszúak byte-ban mérve.
Érdekességeket a char, meg int tipusoknál lehet találni leginkább. A char-ral létrehozott tömb például akármilyen hosszal bírhat. Struktúrán belül használt char nagy valószínűséggel a definiált méreténél fizikailag nagyobb helyet foglal majd, ha egzotikus hosszal definiálod (pl.:3, 15, 61 stb). Másik az int, mert az meg platform függő, hogy milyen széles.
A másik visszaolvasási probléma meg a little/big endian miatt van. Az Intel és a Motorola
processzorok alaptípus ábárzolása például eltérő byte sorrendű. Pl egy 32 bites int 4 byte-ja, nem ugyanazt az értéket jelenti. Fel kell cserélni az adott platformon a más platformon binárisan kiírt 4 byte 2-2 byte-ját, hogy ugyanazt az int értéket kapjuk.
Egyébként az ilyen trükkös platform független bináris állományok kezelésénél jó szolgálatot tesznek a unionok.
Üdv,
t
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)