Gibts was besseres als fgets?
-
Liest du dann wenigstens die Datei mit
fread?
-
Das ist ja nicht zum Aushalten. Ich wette 1000 Gummipunkte, dass es gar nicht nötig ist, die Datei die ganze Zeit vollständig im Speicher zu halten.
-
SeppJ schrieb:
Das ist ja nicht zum Aushalten. Ich wette 1000 Gummipunkte, dass es gar nicht nötig ist, die Datei die ganze Zeit vollständig im Speicher zu halten.
Die hast Du gewonnen. Es ist nicht nötig. Ich mache das auch nicht. Es ist so: Ich weiß nicht, wieviele Punkte und wieviele Elemente in der Datei geschrieben stehen. Jeder Punkt beginnt mit CGRID und jedes Element mit CTRI3 oder CQUAD4.
Ich öffnet die Datei, überprüfe mit strncmp, was der Anfang der Zeile beinhaltet und inkremetiere dann verschiedene Zähler um die Punkte und die Elemente zu zählen. Gleichzeitig schreibe ich die Datei in den Speicher. Auch merke ich mir, wo (also bei welchem Index von Puffer) die Knoten anfangen und wo sie Enden - wo die Elemente anfangen und wo diese enden. Das ist alles sequenziell aufgelistet.
Jetzt wird der Speicher für die Punkte und Knoten allociert.
Im zweiten Durchgang muss ich dann nicht mehr (langsam) aus der Datei lesen, sondern kann auf den Inhalt (schnell) im Speicher zugreifen. In diesem zweiten Durchgang werden dann die Informationen (also z.B. die Koordinaten der Punkte) ausgewertet und die Punkte als structs angelegt. Gleich danach wird der Speicher wieder freigegeben. Und zu einem späteren Zeitpunkt braucht das Programm ohnehin viel mehr Speicher als hier, weshalb es auch nicht schadet, hier mal ordentlich Speicher vom System zu reservieren -ich gebe ihn ja gleich wieder frei.
Und das ist nicht mit Kanonen auf Spatzen geschossen. Eine 1.6GB Datei einlesen dauert. Mit realloc kann ich auch nicht arbeiten, denn es können 36 oder 36 Mio. Elemente in so einer Datei beschrieben sein - 36 Mio. mal realloc macht keinen Spaß.
ÜBRIGENS an Alle: Vielen Dank nochmal, es funktioniert jetzt. Da waren noch ein paar böse Fehler - an ganz anderen Stellen des Codes. Aber grundsätzlich gilt, dass der Absturz mit dem fgets erst nach dem Umstellen auf Plattform x64 gefixt war. Deshalb hat die Routine auch bei kleineren Dateien vorher funktioniert. Also, wir können das schließen!
Eine Frage noch, die ich schon gestellt hatte: Was ist jetzt so schlimm daran, wenn man castet. Ist das einfach ästetisch nicht schön oder gibt es echte Gründe dafür, bei malloc, calloc etc. darauf zu verzichten?
Grüße,
CJens.
-
CJens schrieb:
Eine Frage noch, die ich schon gestellt hatte: Was ist jetzt so schlimm daran, wenn man castet. Ist das einfach ästetisch nicht schön oder gibt es echte Gründe dafür, bei malloc, calloc etc. darauf zu verzichten?
Gründe gegen den Cast:
Es gibt ein paar konstruierte Szenarien, in denen es schlechter ist, weil es Fehler verschleiern kann.
Es zeigt, dass man die genauen Regeln der Sprache C nicht verstanden hat.Gründe für den Cast:
Es gibt keinen Grund dafür. Manchmal wird gesagt, dass der Code dann auch mit einem C++-Compiler compiliert werden kann. Das ist richtig, zumindest so lange der Code nur aus einfachsten Sprachmitteln + malloc besteht. Aber wenn man C mit einem C++ Compiler compiliert, macht man etwas ganz wesentliches falsch.Es gibt also ein paar Argumente gegen den Cast und keine Argumente dafür. Wenn du einfach grundlos überflüssigen Code in deinem Programm haben möchtest, dann mögest du von nun an jeden Ausdruck mit einem doppelten Semikolon abschließen, denn doppelt hält bekanntlich besser!
