Nein, alles in Ordnung: - Record als "packed" deklarieren. - Hinter "Name" (128 bytes) 2 Füllbytes deklarieren - Die Int16 durch Int32 (LongInt) ersetzen.
Dies hier liest die Datei problemlos ein und zeigt vernünftig aussehende Werte (Formular mit Memo):
Der Übeltäter war anscheinend, das ein normaler Record, gar nichts packt und der packed record dies sehr gründlich macht, und C macht eine Mischung aus beiden. Darum die beiden Füllbytes.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Vielen Dank für Eure Hilfe. Ich hätte bestimmt noch einige Zeit gedoktort (und wahrscheinlich dann doch Wert für Wert eingelesen). Den Verdacht, dass Pascal binär anders speichert als C hatte ich ja von Anfang an. Aber da wäre noch viel rum zu testen gewesen.
Aber die große Lehre bleibt: am besten, man speichert solche Daten in irgendeinem ASCII-Daten-Format
Den Verdacht, dass Pascal binär anders speichert als C hatte ich ja von Anfang an.
Das hier ist noch heilig, probiere mal Daten zwischen Pascal und Java auszutauschen, da bin ich auch mal fast die Wände hoch gegangen. Das einte System hat bigendian und das ander littleendian. Ich wollte Vertex-Daten, welche ich mit Lazarus erzeugte in einer Android-App nutzen. Unter Java war ich da auch neu, und das Forum zu Java eine Katastrophe, nicht zu vergleichen mit dem Forum da.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Den Verdacht, dass Pascal binär anders speichert als C hatte ich ja von Anfang an.
Das hier ist noch heilig, probiere mal Daten zwischen Pascal und Java auszutauschen, da bin ich auch mal fast die Wände hoch gegangen. Das einte System hat bigendian und das ander littleendian. Ich wollte Vertex-Daten, welche ich mit Lazarus erzeugte in einer Android-App nutzen. Unter Java war ich da auch neu, und das Forum zu Java eine Katastrophe, nicht zu vergleichen mit dem Forum da.
Das problem hatte ich auch letzens, als ich dabei war Minecraft Welten einzulesen/zu speichern. Das ist echt eine Qual.
MFG
Komoluna
Programmer: A device to convert coffee into software.
Um das Thema abzuschließen: Man kann sich das explizite Einfügen von Füllbytes in die Recorddefinition sparen, indem man, wie weiter oben angedeutet, die Direktive {$PackRecords 4} verwendet; der Typ TRoadLoadData ist dann nur als "record", nicht mehr als "packed record" zu deklarieren. Das oben verwendete {$Packrecords C} führt bei mir zum Absturz.
Allerdings weiß ich nicht, wie die Direktive gilt, wenn mehrere Alignments in verschiedenen Records vorkommen, also: 1.Record soll {$PackRecords 4} haben, 2.Record soll als "packed record" deklariert sein (d.h. {$PackRecords 1}), etc. Gilt das Datei-weit, oder bis zum nächsten $Packrecords?
die Direktive {$PackRecords 4} verwendet; der Typ TRoadLoadData ist dann nur als "record", nicht mehr als "packed record" zu deklarieren.
Habe es gerade probiert, und es geht ?
Beim experimentieren oben ist mit aufgefallen, das die Records gleich aussehen, egal ob ich 32 oder 64Bit kompiliere. Müsste es bei einmal eine 4Byte und einmal eine 8Byte Ausrichtung haben ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot
Ich denke, wenn du 4-byte Alignment einstellst (oder eben mit packed record die zwei Füllbyte einbaust) ist alles in Ordnung, egal ob 32 oder 64 bit. Du teilst dem 64-Bit Compiler durch die Direktive ja mit, er solle 4-byte Alignment nehmen, obwohl er standardmäßig 8-byte nehmen würde. Und 4-byte Alignment ist das was du brauchst, weil alle Recordelemente in der Datei bei durch 4 teilbaren Offsets beginnen, das sieht man im Hex-Editor.