Egy file-ból szeretnék soronként két adatot kiolvasni attól függetlenül, hogy van-e benne több. Hogyan érdemes (részletek alant)?

Mire kell ez a nagy sebesség? Nem hiszem hogy nagyon számítana (kivéve ha nincs rá vmi nyomós okod) több magos több GHz-s több giga RAM-os gépen.

Akkor használd az ANSI c-s fscanf-et, és ANSI c-s string-eket.

Miért nem jó a getline? Gondold végig: beolvasol két adatot, akkor még mindig abban a sorban vagy, tehát ha megfordítod, és először beolvasol két adatot, és utána hívsz getline-t, akkor pont jó:

std::fstream myFile;

//open

std::string str;

int adat1, adat2;

while (myFile)

{

myFile >> adat1 >> adat2;

std::getline(myFile, str);

}

"Az első válaszoló elmehet a sunyiba, nem tudom minek irogat."

Mi az hogy minek írogat? Fscanf-el is tényleg meg lehet oldani.

"Mondhatnám hogy fusd körbe a házatokat 10-szer, mert van rá elég hájad, tehát fölösleges spórolni."

Nem azt írtam hogy rakjál bele egy felesleges for ciklust mert úgy sem oszt szoroz hogy benne van vagy nincs ígyis úgyis van rá elég energiája a gépnek.

Mivel ordóba ugyan az a futási idő, ami amúgy lineáris idejű, kis konstans szorzóban különbözik csak, ami gyakorlatilag gyors. Még egy p2-es gépen sem számítana, feltételezem hogy jobb géped van annál. Próbáld ki ígyis úgyis mérd le hogy mennyivel gyorsabb és örülj a "nagy" haszonnak. Én olyan dolgot szeretek optimalizálni aminek értelme/érezhető hatása van. Olyan optimalizálás ami 1-2 milisec-et gyorsít, vagy annyit sem, az feleleges időpazarlás abba energiát spórolni, persze az megint más ha hobbiból vagy gyakorlásból csinálja az ember.

Futási idő elemzés az egy fontos területe a programozásnak, tudni hogy hol kell optimalizálni és hol nem számít.

"energiát spórolni"

energiát fektetni

Fölösleges ezzel ennyit trükközni, ezzel egyetértek, de iostream megoldása (szokás szerint) tökéletes a célra.

Ez a legelegánsabb és legegyszerűbb, ugyanis az inputot csak szekvenciálisan tudod olvasni így, tehát valahogy mindenképpen a sor végére el kell jutnod.

"Csak úgy" nem fogsz tudni sort ugrani.

Használd ezt a verziót.

(Amúgy ebben tévedsz: "Nem milisec, hanem kétszer annyi" és a másik válaszolónak van igaza.

Mert ugye a sort 1* olvasod végig, majd másodjára csak az első 2 részt szeded ki. Nem dolgozod fel még egyszer az egészet, mer ha tárolva van már egy sorod, akkor tudsz ugrani a következőre. Nagyon kicsi lenne itt az eltérés az iostream féléhez képest.)

"Nem milisec, hanem kétszer annyi, mint egyébként, vagy másfélszer, és a sok kétszerese számít."

Nem lepődnék meg ha nem haladná meg a 10%-ot a sebességkülönbség, a fájl hozzáféréshez is idő kell, a kiolvasás string kezelés függvényhívás ideje hogy aránylik egymáshoz függ az OS-től, a hardvertől, a gyorsítótáraktól ...

Még régen amikor a pentium volt a legújabb processzor akkor csináltam programot ami egy szótárból kikeresi a begépelt string része vagy egésze az angol kifejezésnek az ember és amely sorokra illeszkedett azokat eltárolta egy tömbre és lehetett nyilakkal irányítani hogy mely találatokat írja a képernyőre, a programom minden billentyű lenyomásra újra kereste az egész szótárat sima "nyers erővel" (haverom mondta az lassú lesz, de nem úgy volt) és így is simán keresett olyan gyorsan mint ahogy gépelek. Nem túlzás ha kb 1600-2000 A4-es oldal lenne kinyomtatni szokásos betűmérettel. Ha XY megcsinálta volna 2x lassabbra a programot mint én, akkor egy mai gépen futna legalább olyan gyorsan mint az enyém azon a gépen.

Szóval nem szubjektíven kell megítélni és optimalizálni. Sok gyakorlás után az ember helyes következtetéssel kapásból látja sokszor (nem mindig) hogy ott nem érdemes optimalizálni, na emitt meg igen.

Ahhoz nagyon nagy input kéne hogy lényeges legyen az a sebességkülönbség amit te vetettél fel kérdező. Ez esetekbe meg keresőfákat vagy valamilyen más adatszerkezetet használnék, tesztelném melyik a (közel) legideálisabb.

"while (!inFile.eof()) vagy valam ihasonló kéne nem?"

Ezt iostream leírta akkor olvasd el még egyszer!