"Mire válaszoltam: nem mindig 4B a feldolgozás tárgya. Konklúzió: Igazad van, de csak akkor, ha erre a függvényre nics szükség. Akkor meg nekem van igazam: Gyorsabb a BE."
Igazan mutathatnal meg peldat ahol a BE gyorsabb mert nem hiszem, hogy az iranyitoszamok osszehasonlitasa ennyire szeleskorben elterjedt problema lenne. (Raadasul pont 4B-os, tehat ntohl() es meg van oldva.) A BE tovabbra sem gyorsabb csak egy corner case-t talaltal.
"Ha beolvasta, kezelem. Eddig rendben. Ha nem, sajnos a program kilép. -> Szerelő, hw hiba van. Más esetben az előző programot kell javítani. Ezt tényleg nem tréfának szántam."
Gondolom tisztaban vagy azzal, hogy a read() visszaterhet hibaval/vartnal kevesebb beolvasott adattal akkor is ha nincs hw hiba es a hivas megismetlese eseten a vart eredmenyt kapnad. Ez csak egy pelda volt arra, hogy mennyire nem mindegy a hibakezeles kihagyasa. ;)
"Ha 0 van egy 8M soros text fájlban, (még mindig text feldolgozás) az nem lehet más, mint memóriahiba."
Nem gondolod hogy ebben az esetben jobb lenne leallni mint esetleg osszefirkalni az addig helyes adatokat?
Amugy lehet mas is:
- merevlemez hiba
- elozo programban kihagyott write hibakezeles es nem is ment ki a puffer ;)
- ebben a programban kihagyott read hibakezeles es nem is lett megtoltve a puffer ;)
...elvegre a hibakezelestol csak nagyobb eselye lesz a hibaknak. :)
(Mellesleg mi a fenenek is irogatsz text fajlokat a programok kozott?)
"A teljes programrendszeren kb. 50 optimalizálást végeztem a diszkek hangolásán, és adatszervezésen át az adattartalom javításáig. Eközben a futásidő nyolcada lett az eredetinek."
Gondolom ebbol valami hatalmas darab lehet az, hogy int-kent kezelsz 4 karaktert. :)
"Vegyél. Az én rendszereimet 2 perc alatt tudta javítani akár egy félhülye operátor. Legalábbis teszteltük, de nem került rá sor 10 év alatt."
Megneznem a 2 perc alatt alaplap- vagy tapcseret amit ra mersz bizni a felhulye operatorra a sok millios gepen. Sot, azt is megneznem akar amikor a felhulye operatorra rabizod a backup visszaallitasat.