Sziasztok!
Hát lehet én vagyok hülye, illetve azt hiszem belefutottam valami architektúrális(??) eltérésbe.Szóval, a program feladata ez lenne:
Te megadsz 3 számot 1 és 8 között, ami egy helyiértéket képvisel. (8 bit, kettes számrendszer)
Adott egy bemeneti fájl, majd ezen a fájlon kéne végigmenni bájtonként(be.doc), és 2x3 számlálót inkrementálni a a megadott helyiértékeken lévő értékek (0,1) szerint.
Szóval kvázi megszámolja, hogy adott helyiértéken hány helyen van 1-es vagy 0 a bemeneti fájl bájtjaiban.
Probléma:
Nállam jónak tűnik a futás az eredménye(win7 beta, devcpp 4.9.9.2), a család másik gépén(win xp, devcpp 4.9.9.2 és ubuntu 8.10, gyári gcc) is ugyan azt dobja, sőt 2 suliszerveren is(valamilyen linux...). Azért gondolom, hogy jó, mert az adott helyen lévő 0-ák és 1-esek számának összege = a fájl méretével.
Viszont 2 ismerősöm összesen 4 gépén más eredményt ad, ott az egyesek számát egyszerűen nullának véli.
Tehát, mint ahogy már írtam: akkor ez most hogy/miért?
(lehet, hogy a program (is) hibás? nem tudom)
Program forráskódja: http://pastebin.com/m7cbf0e6a
A válaszokat/megjegyzéseket előre is köszönöm!
Hozzászólások
Próbálgatás után:
a long long int-ekkel van gond, ha long int-re cseréltem őket, akkor jól működik.
Azok a gépek, amiken jól működtek, nem 64 bitesek véletlenül? Az én gépem 32 bites, és csak 0-kat írt ki összegnek, ami nehezen hihető.
Az már egy másik külön apróság, hogy (szerintem) az EOF-ot is beleszámolod.
"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series
Köszi a választ!
Elgondolkodtató a 64 vs 32 bit kérdés, ennek utánna járok, illetve amit tudok, az az, hogy az én gépem elvileg 64 bitet is tudna(celeron m520, merom mag), de 32 bites oprendszereket haszálnok, haver (egyik) gépe szintúgy(valami core 2 t2xxx), 32 bites win.
Igen, lehet beleszámolom az EOF-ot is, de csak statisztikai számításokra kell, konkrétan egy word dokumentumban mik a jellemző arányok a bitekre nézve, és megfelelően nagy fájl esetén nem sokat számítana.(matekszakos havernak írtam)
Amúgí közben látom, hogy fájlírás-hibánál 2x fogja kiírni az eredményt a monitorra, de az mindegy.
A dolog kezd érdekessé válni, ugyanis ugyanazon a gépen a 64 bites ubuntun (szerintem) jól működik a progi.
Amúgy 2 dolog a programmal kapcsolatban:
- a karakterenkénti beolvasás nem túl jó (és főleg, nem túl gyors) dolog, inkább egy nagyobb bufferbe kellene olvasni, és azt feldolgozni.
- ha egy tömböt inicializálásnál ki akarsz nullázni, akkor elég ez: típus változó_név[ méret ] = {0}; /* az egesz tomb nullazva lesz */
"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series
Hümm... érdekes, köszi a tippeket.
A sebesség nem szempont most, csak hirtelen összedobtam, viszont megfogadom tanácsod.
Akkor is érdekes, szóval egy 64 bites proci 32 bites oprendszer esetén másképpen kezelné az int-et?
Illetve az oké, hogy 64 bites proci + 64 bites oprendszer az más eset, mint a 32 bites proci és 32 bites oprendszer.
szerk.: amúgy tényleg elég a long int, az is elmehet pár millió/milliárdig, szóval feleslegesen használtam, de mindig tanul valamit az ember.
Annyira nem látom más esetnek a 64 bites procin való 32 bites oprendszer futtatását, mivel a 64 bites procik is rendelkeznek a 32 bitesek utasításaival, illetve ezek vannak kibővítve (gondolom én).
Amúgy lehet, hogy rossz irányba viszlek el, mivel én is csak találgatok. Lehet, hogy az oprendszerek kezelnek másként dolgokat, lehet, hogy a fordítókban van valami eltérés. A gond az, hogy ha a szabvány nem nyilatkozik egyértelműen valamiről, akkor annak az értelmezése a fordító írójára van bízva, ami eredményezhet különböző működést ugyanarra a kódra. A C szabványban pedig elég sok minden van, ami nincs definiálva.
"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series
De, ha tegyük fel ugyan azzal fordítom mindkét gépen, és mindkét gép elvileg képes 64 bites programot futtatni, de csak 32 bites módban használom, akkor elvileg ugyan azt kéne dobnia. Legalábbis úgy gondolom. :(
C-sebb megoldás lenne, ha letárolnád az
értéket, majd a beolvasott byte-ra már csak egy & kell és megkapod, hogy 1-es vagy 0. Nomeg karaktert se szokás fscanf-el beolvasni...
A hibára rátérve: long long csak a '99-es C szabványban jelent meg.
A gcc ismeri ezt a '89-es szabvánnyal is, de ott ez csak gcc feature.
Éppen ezért a libC printf-je nem biztos, hogy tudja, hogy mi az az %lld
(egyébként %llu kéne, mert unsigned).
Jobb ötletem nincs...
Egyébként meg amíg nem próbálkozol 4Gb-nál nagyobb fájlokkal, bőven elég az unsigned int.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Szia!
Most, hogy jobban utánnanéztem, rájöttem, hogy tényleg butaság a long long int-et használni, mivel max pártíz megás fájlokról volna szó.
Nomeg karaktert se szokás fscanf-el beolvasni...
Amúgy csak kezdő vagyok, mint látszik, és az oktatás nem tér ki ezen részletekre. Szóval csak annyira kell tudni programozni, hogy menjen. Ez tudom, hogy baj, többet kéne utánnaolvasnom, nameg fél év alatt nem lehet megtanulni profi szinten C-ben programozni. :(
Köszi a kritikákat, utánnanézek.
Szerintem kezdesnek ti is fgetc-vel olvastatok a fajlbol... no de mindegy is.
--