[C++] lezen vanaf x lines van EOF?

[Whuzz]

Ik heb een progje dat een logfile uitleest en daarvan heb ik alleen de laatste paar regels nodig. Ik wil dus eigenlijk pas beginnen met lezen bij de laatste 5 regels ofzo, maar dat krijg ik dus niet voor elkaar. Ik heb me wezenloos gezocht, maar het enige dat ik kan vinden is een manier om een x-aantal characters vanaf EOF te gaan lezen. Dat werkt wel ongeveer, maar aangezien de regels niet allemaal uit evenveel characters bestaan krijg ik daarmee niet telkens hetzelfde aantal lines terug.

code:

examplefile.seekg(-350, ios::end);

Dat heb ik nu, hij zet de pointer dan dus 350 tekens vanaf het einde van de file. Maar ipv 350 tekens wil ik daar dus 5 regels van maken. Hoe doe ik dat??

[Exirion]

Logisch nadenken. Bedenk eens een simpel algoritme om zoiets te doen ipv naar kant en klare oplossingen te zoeken.

[RobIII]

Whuzz schreef op 12 juni 2004 @ 04:32:
Ik heb een progje dat een logfile uitleest en daarvan heb ik alleen de laatste paar regels nodig. Ik wil dus eigenlijk pas beginnen met lezen bij de laatste 5 regels ofzo, maar dat krijg ik dus niet voor elkaar. Ik heb me wezenloos gezocht, maar het enige dat ik kan vinden is een manier om een x-aantal characters vanaf EOF te gaan lezen. Dat werkt wel ongeveer, maar aangezien de regels niet allemaal uit evenveel characters bestaan krijg ik daarmee niet telkens hetzelfde aantal lines terug.

code:

examplefile.seekg(-350, ios::end);

Dat heb ik nu, hij zet de pointer dan dus 350 tekens vanaf het einde van de file. Maar ipv 350 tekens wil ik daar dus 5 regels van maken. Hoe doe ik dat??

Dat kan "makkelijk" als alle regels een vaste lengte hebben. Dan lees je gewoon vanf eof - (tekensperregel * aantalregels), anders moet je gewoon bijvoorbeeld de laatste 1024bytes (1k lezen) en er effe doorheen lussen (na een split op CrLf) ofzo.

[Whuzz]

Exirion schreef op 12 juni 2004 @ 04:48:
Logisch nadenken. Bedenk eens een simpel algoritme om zoiets te doen ipv naar kant en klare oplossingen te zoeken.

Als ik er nog niet over nagedacht zou hebben, dan zou ik het hier niet gepost hebben
Ik had al wat geprobeerd met hem alle regels te laten tellen, daar 5 van af te trekken en hem dan alle regels behalve die laatste 5 te laten discarden, maar dat is te omslachtig, omdat die logfile vrij groot kan worden, ik wil due (als dat te vermijden is niet alle regels hoeven door te lezen.

RobIII schreef op 12 juni 2004 @ 05:20:
Dat kan "makkelijk" als alle regels een vaste lengte hebben. Dan lees je gewoon vanf eof - (tekensperregel * aantalregels), anders moet je gewoon bijvoorbeeld de laatste 1024bytes (1k lezen) en er effe doorheen lussen (na een split op CrLf) ofzo.

Zoals ik al schreef:

(...) maar aangezien de regels niet allemaal uit evenveel characters bestaan krijg ik daarmee niet telkens hetzelfde aantal lines terug.

Wat jij zegt is exact wat ik nu al doe
En dat werkt dus maar half, omdat ik nu niet telkens een gelijk aantal regels terugkrijg...

[Anoniem: 70162]

ik weet niet hoe groot je bestand is, maar als je nou eens 5 strings maakt, en gewoon vooraan begint met lezen. regel 1 in string 1, regel 2 in string 2, etc. regel 6 dan weer in string 1, regel 7 in string 2.
bij OEF stop je (of naja, dat gebeurt vanzelf ), dan heb je dus de laatste 5 regels in 5 strings staan.

eventueel laat je nog een integer meetellen welke string je als laatste had, dat sorteert wat makkelijker.

[ Voor 6% gewijzigd door Anoniem: 70162 op 12-06-2004 12:16 ]

[Shadowman]

Whuzz schreef op 12 juni 2004 @ 12:09:
Zoals ik al schreef:

[...]


Wat jij zegt is exact wat ik nu al doe
En dat werkt dus maar half, omdat ik nu niet telkens een gelijk aantal regels terugkrijg...

Dat wat jij nu zegt is volgens mij niet exact het zelfde als wat RobIII zegt. Wat RobIII bedoelt is dat je aan het eind een aantal tekens inleest die sowieso groter is dan de 5 regels die je moet hebben en dan daaruit de laatste 5 regels haalt.

[Whuzz]

@ gunhead: Dat logbestand kan HEEL groot worden, dus ik wil graag vermijden dat ie elke keer dat hele bestand af moet lopen.

@ shadowman: Je hebt gelijk. Ik had over de laatste regel heengelezen. Ik had zoiets al geprobeerd, maar dat lukte niet. Ik zal nog even verder puzzelen in die richting.
Er bestaat dus geen routine om gewoon vanaf x-regels van EOF te beginnen met lezen?

[Update] Volgens mij is het nu gelukt...

- Open bestand en ga naar EOF - 500 chars (dan heb ik zeker weten de laatste 5 regels.
- Tel het aantal regels.
- Neem aantal regels - 5 => startregel
- Ga weer naar EOF - 500
- Loop door alle regels, wanneer regelnummer > startregel, verwerk de regel.

Tnx voor de hulp!

[ Voor 30% gewijzigd door Whuzz op 12-06-2004 13:23 ]

[PommeFritz]

Misschien heb je wat aan de source van het 'tail' commando uit Gnu-textutils. Moet je het perse inbouwen in je eigen code? Kun je niet gewoon 'tail' aanroepen?
Dat ding heeft ook een 'follow' optie, super handig.

[Zoijar]

Je kan toch gewoon naar het eind seeken, dan steeds een character meer terug lezen en kijken of het een EOL is? Dan begin je een char na de laatste EOL die je leest.

[Exirion]

Zoijar schreef op 12 juni 2004 @ 13:24:
Je kan toch gewoon naar het eind seeken, dan steeds een character meer terug lezen en kijken of het een EOL is? Dan begin je een char na de laatste EOL die je leest.

Byte voor byte teruglezen is natuurlijk ranzig Het is beter om logaritmisch terug te lezen: begin met bijvoorbeeld 256 vanaf het einde van de file, dan 512, dan 1024, etc... net zolang tot er in de buffer 6 EOFs voorkomen. En dan begin je te 'lezen' vanaf net na de eerste EOF (lezen in je buffer dus).

[Zoijar]

Exirion schreef op 12 juni 2004 @ 13:27:
Byte voor byte teruglezen is natuurlijk ranzig Het is beter om logaritmisch terug te lezen: begin met bijvoorbeeld 256 vanaf het einde van de file, dan 512, dan 1024, etc... net zolang tot er in de buffer 6 EOFs voorkomen. En dan begin je te 'lezen' vanaf net na de eerste EOF (lezen in je buffer dus).

Ja ach, het gaat om 5 regels, je disk heeft dat block toch waarschijnlijk gecached. Als het dus 520 vanaf het einde is, dan denk dat je logaritmische manier misschien zelfs nog wel langzamer is. Waarom zou je allemaal ingewikkelde dingen gaan doen voor het terug lezen van 5 regels, iets dat toch vrijwel geen tijd kost.

Asl je in ieder geval maar niet alle regels gaat tellen, want dan wordt het een O(n) operatie terwijl het makkelijk in constante tijd kan.

[ Voor 10% gewijzigd door Zoijar op 12-06-2004 13:43 ]

[Exirion]

Zoijar schreef op 12 juni 2004 @ 13:38:
Ja ach, het gaat om 5 regels, je disk heeft dat block toch waarschijnlijk gecached. Als het dus 520 vanaf het einde is, dan denk dat je logaritmische manier misschien zelfs nog wel langzamer is. Waarom zou je allemaal ingewikkelde dingen gaan doen voor het terug lezen van 5 regels, iets dat toch vrijwel geen tijd kost.

Deze houding heeft software er in de afgelopen jaren niet efficienter op gemaakt ('oh, we hebben zat geheugen en zat cpu power'). Met iets meer effort is vanalles een stuk efficienter te maken, maar goed... da's een discussie op zich

[Zoijar]

Exirion schreef op 12 juni 2004 @ 13:43:
Deze houding heeft software er in de afgelopen jaren niet efficienter op gemaakt ('oh, we hebben zat geheugen en zat cpu power'). Met iets meer effort is vanalles een stuk efficienter te maken, maar goed... da's een discussie op zich

Dat is niet echt mijn houding, aangezien ik altijd te weining geheugen en altijd te weinig cpu power heb Maar je moet wel alleen optimizen wat nodig is. Je tijd was waarschijnlijk veel beter besteed om die innerloop een paar tikken sneller te maken, dan dit duizenden tikken sneller te maken.

[Whuzz]

Gave discussie, maar dit is mijn eerste projectje, dus hoeveel CPU en mem het gebruikt zal mij de spreekwoordelijke reet roesten

Maar het is natuurlijk beter om vanaf het begin te leren efficient te coden.

[Anoniem: 13700]

Zoijar schreef op 12 juni 2004 @ 13:46:
Dat is niet echt mijn houding, aangezien ik altijd te weining geheugen en altijd te weinig cpu power heb Maar je moet wel alleen optimizen wat nodig is. Je tijd was waarschijnlijk veel beter besteed om die innerloop een paar tikken sneller te maken, dan dit duizenden tikken sneller te maken.

Dit gaat niet over optimizing maar over het kiezen van een efficiënter algoritme. Een ongeoptimaliseerd efficiënt algoritme verslaat een super-geoptimaliseerd houtkakkersalgoritme als de input groot genoeg is (quicksort of heapsort in javascript wint hoogstwaarschijnlijk van bubblesort in assembly met 10 miljoen te sorteren elementen).

[Zoijar]

Anoniem: 13700 schreef op 12 juni 2004 @ 15:57:
Dit gaat niet over optimizing maar over het kiezen van een efficiënter algoritme. Een ongeoptimaliseerd efficiënt algoritme verslaat een super-geoptimaliseerd houtkakkersalgoritme als de input groot genoeg is (quicksort of heapsort in javascript wint hoogstwaarschijnlijk van bubblesort in assembly met 10 miljoen te sorteren elementen).

Wat je zegt is zeker waar, maar onder optimalisatie valt natuurlijk ook het kiezen van een sneller (en vaak ingewikkelder) algoritme. Zelfs dan moet je ook altijd een beetje uitkijken met theoretische en empirische complexiteit. Zo kan een O(n^2) soms sneller zijn dan een O(nlogn) vanwege hoge constanten, of veel duurdere operaties.
Maar ik denk dat we allebei wel weten waar het over gaat. Mijn punt was dat je bv geen complex en error prone O(nlogn) algoritme gaat implementeren tov een heel simpel en duidelijk O(n^2) als je van te voren al weet dat je n niet groot is (zeg 5 )