fread() hat den Zeiger ja schon verschoben, das fseek(SEEK_CUR) mit
positivem offset geht weiter ins unentdeckte Land. Ein quick fix koennte
ein fseek(fp, -(intsize-1), SEEK_CUR) zu beginn des loop sein.
Cheers, Roger
Philipp K. schrieb:> ich habe versucht den Dateizeiger beim einlesen einer Textdatei mit> einer Schleife an Newline auszurichten..
Wenn Du Dich am Newline "ausrichten" willst, solltest Du keine
blockorientierte Funktion verwenden, sondern eine, die sich auch am
Newline "ausrichtet". Nennt sich fgets(). Das Lesen in Blöcken übernimmt
stdio sowieso schon für Dich, von daher ergibt sich überhaupt keine
Performance-Einbuße.
Darüber hinaus kann man sich den fseek-Kram sparen.
Danke für die Antworten.
Ich habe wohl zu später Stunde das einfachste übersehen und dann noch
Fehler eingebaut.
Die Lösung scheint der Binarymodus zu sein.. beim abändern des Codes um
den Fehler einzugrenzen habe ich dann noch einen Fehler eingebaut.
Normalerweise hatte ich die Variable Seekoffset neben nlpos
runtergezählt.
Frank M. schrieb:> Das Lesen in Blöcken übernimmt stdio sowieso schon für Dich, von daher> ergibt sich überhaupt keine Performance-Einbuße.
Das ist ja nur ein Test die Chunks sind 150MB groß. Mich interessiert
der Unterschied.
Dirk B. schrieb:> Welche Warnung kommt in Zeile 7 und 20 ?
OK mache ich, normalerweise nur Pointer vs Integer comparison beim If.
Philipp K. schrieb:> Die Lösung scheint der Binarymodus zu sein.
Du liest eine Text-Datei, jedenfalls hast Du das oben geschrieben.
Das Problem ist unter Windows: Im Textmodus werden die CRLF-Paare (\r\n)
zu einen LF (\n) gemapped. Von daher kann man sich schnell in der
Position "verzählen". Komplizierter wird es, wenn Du unter Windows eine
Unix-Datei einliest. Da ist dann gar kein CR (\r) drin.
Umgekehrt unter Unix/Linux: Hier findet kein Mapping statt - egal ob Du
eine Windows-Datei oder Unix-Datei einliest. Und das ist dann noch
unabhängig, ob Du die Datei im Binär- oder Textmodus öffnest. Vorteil:
"Verzählen" kann man sich hier nicht.
> Das ist ja nur ein Test die Chunks sind 150MB groß.
Was für Chunks? Ich dachte, es geht um eine Text-Datei?
> Mich interessiert der Unterschied.
Welcher Unterschied?
Frank M. schrieb:> Du liest eine Text-Datei, jedenfalls hast Du das oben geschrieben.
Ja, ich weiß aber schon wie das Byte aussieht, also kann ich die auch in
Bytes lesen. Die kann aber auch 1GB groß sein. Von Byte zu Char ist ja
jetzt nicht die Welt.
Frank M. schrieb:> Das Problem ist unter Windows: Im Textmodus werden die CRLF-Paare (\r\n)> zu einen LF (\n) gemapped.
Das habe ich auch schon herausgefunden, dazu noch die ganzen
Problematiken. Fseek64 etc.
Frank M. schrieb:> Welcher Unterschied?
Ob fgets nicht vielleicht einen Overhead produziert. Mir sind die
Newlines nicht wichtig, für diesen Fall der Optimierung der mich
interessiert darf zwischen zwei Newlines kein Buffer enden und kein
buffer anfangen. Das war meine Idee.
Philipp K. schrieb:> OK mache ich, normalerweise nur Pointer vs Integer comparison beim If.
Und das wundert dich nicht?
Da hast du einen Fehler. Der ist zwar nicht in der Zeile mit dem if,
aber führt dazu dass dein Programm nicht funktioniert.
Dirk B. schrieb:> Da hast du einen Fehler. Der ist zwar nicht in der Zeile mit dem if,> aber führt dazu dass dein Programm nicht funktioniert.
Naja, gewundert habe ich mich schon..
Mein eigentliches Programm lief schon, nur das fread mit fseek nicht
dort wo ich dachte gestartet hat. Wie hier schon geschrieben wurde liegt
das an der Implementierung von fread bei erstellen eines Dateizeigers im
Textmodus "r" anstatt "rb". Wobei es noch andere Seiteneffekte gibt. Ich
teste das auf onlinegdb.com, da muss man erst auf Debug umstellen damit
man den Kern des SegFaults bekommt.
Den Fehler habe ich bei reduzierung des eigentlichen Problems
eingebaut.
Danke, ich werde das mal auf dem Rechner anschauen, bin gespannt.
Klappt nicht. Dann muss ich mir etwas anderes überlegen.
ftell liefert immer ein Vielfaches von buffersize egal wie ich mit
SEEK_SET oder SEEK_CUR die Position verschiebe.
Hat das vielleicht mit einer Optimierung vom Compiler zu tun?
EDIT: scheint doch zu laufen, habe da einen Workaround gefunden.
Philipp K. schrieb:> Da habe ich mich wohl bei der Fehlersuche verstrickt.. das war vorher> eine Initialisierung mit malloc.
Kann passieren... und so ein Fehler ist dann besonders tückisch, weil es
mal läuft und mal nicht, und immer wieder andere Fehler auftreten aber
irgendwie keine sinnvolle Ursache zu finden ist... :-o
Philipp K. schrieb:> Mathias A. schrieb:>> Das ist doch ein Array von Pointern auf char, und kein Array von chars,>> oder?>> Ja, ups ich glaube das wars
Das ist die Ursache für die von mir erwarteten Warnungen - und die
Aussage, dass das Programm nicht funktioniert.
Aber hey, das ist ja „nur“ eine Warnung. Die muss man nicht beachten.
Dirk B. schrieb:> Aber hey, das ist ja „nur“ eine Warnung. Die muss man nicht beachten.
Ich hatte diese Warnung nicht.. Außerdem hab ich da zuviel
verschlimmbessert um das Beispiel klein zu halten.
Mathias A. schrieb:> Ursache zu finden ist... :-o
Jo.
Sebastian schrieb:> Was passiert denn am Dateiende wenn nur noch weniger als 127 Bytes zu> lesen sind?
Es ist ja nur ein Problembeispiel. Man muss die Dateigröße auf die
durchlaufenen Blöcke gegenrechnen und einen definierten Abschlussblock
der Restgröße hinter der Schleife lesen.
Meine Idee war da, die Blockgröße zur Dateigröße anzupassen und unter
der Buffergröße nur einmal einzulesen.