CSV-Datei einlesen

[Mathias]

Warum arbeitest du überhaupt mit fpc-trunk? Wenn sich da ein Fehler einschleicht, hast du erheblich mehr Aufwand, wieder ein lauffähiges System zu bekommen als mit Lazarus Trunk (fpc-trunk neu zu kompilieren ist immer ein Abenteuer, zumindest für mich). Und die neuen Features? Sie machen abhängig von dieser Version und man kann nicht mehr zu stable zurück. Für mich sind das Gimmicks für Leute, die von anderen Sprachen kommen und die Syntax dieser Sprachen auch in Pascal haben möchten (genau sowas wie das "s.Split", oder "s.Length" eben). Und wenn man Komponenten schreibt, sind die Neuerungen wegen der Inkompatibilität zu älteren Versionen sowieso tabu. Ich selbst verwende fpc-trunk nur, um gefixte fpc-Bugs zu testen, die ich gemeldet habe.

Genau, wegen den Typen helper finde ich die aktuelle Trunk interessant.

[mse]

TTextDataStream von MSEgui hat Funktionen um CSV-Records zu lesen und zu schreiben:

Code: Alles auswählen

 
 ttextdatastream = class(ttextstream)
[...]
   procedure writerecord(const fields: array of const); overload;
[...]
   function readrecord(fields: array of pointer; types: string): boolean; //true if no error
                // b -> boolean
                // i -> integer
                // I -> int64
                // s -> ansistring
                // S -> msestring
                // r -> real
   property separator: msechar read fseparator write fseparator default ',';
   property quotechar: msechar read fquotechar write fquotechar default '"';
   property forcequote: boolean read fforcequote write fforcequote default false;
 

https://gitlab.com/mseide-msegui/mseide ... stream.pas

[vlenzer]

TTextDataStream von MSEgui hat Funktionen um CSV-Records zu lesen und zu schreiben:

Danke für den Tipp, ich halte mich aber erstmal an wp_xyz.

Bringt es eigentlich größentechnisch was, wenn ich die als Double gespeicherten Variablen vorm Schreiben in die neue CSV-Datei wieder in einen String überführe? Die Datei müsste doch dann kleiner sein, oder? Oder übernimmt der Befehl "writeln" Das eh schon, weil er nicht mit Zahlen, sondern nur mit Strings umgehen kann?

[wp_xyz]

Nur wenn du bewusst rundest. Aber das solltest du bei Gleitkommazahlen sowieso nicht machen - wegen Genauigkeitsverlust.

Wenn es dir auf die Größe der Datei ankommt, dann speichere die Zahlen binär. Jede Double-Zahl belegt in dieser Datei, binär codiert, 8 Byte (gegenüber etwa 25 als String mit voller Genauigkeit plus Spaltentrennzeichen) Beim Einlesen ersparst du dir auch das Zerlegen des Strings, d.h. das sollte auch schneller gehen. Allerdings kannst du diese Dateien nicht mehr in einem Editor anzeigen oder in Excel einlesen (aber das ist bei GByte-Dateien sowieso hypothetisch).

[Mathias]

Und wen man Single anstelle Double nimmt, halbiert sich der Speicher nochmals.
Für 90% der Anwendungen reicht Single locker.

String auf Gleitkommazahlen Berechnung braucht sehr viel Zeit, nimm mal einen Arduino und dann wirst du dies richtig merken.

[Mathias]

Meinst du so was ?
Die Test-SVN ist immer noch die gleiche wie oben.

Code: Alles auswählen

    sa := s.Split(';');

Zeig ihm doch nicht sowas. Der OP ist Anfänger, und man sollte ihm vor allem nicht zumuten, fpc-trunk zu installieren.

So wie es scheint, wird innert kürze die Trunk dafür nicht mehr gebraucht. Von fpc 3.0.2 ist schon die RC1 im Umlauf.
Ich habe es grade unter WinXP dir RC1 getestet.

[wp_xyz]

Nein, das mit Trunk war nicht richtig meinerseits: Type helpers gibt es jetzt schon bei fpc 3.0.

[Mathias]

Type helpers gibt es jetzt schon bei fpc 3.0.

Das stimmt, aber es war noch nicht perfekt, ich hatte dazumal einen Thread dafür geöffnet.
viewtopic.php?f=10&t=9286&p=83629&hilit=type+helper#p83629

Und wie oben beschrieben, wurde es noch nicht so stark in die RTL integriert. ZB. String.Splitt.
Auch hat es noch Funktionen mit TPointF gegeben.

Auf jeden Fall ist es eine Erleichterung, das ich dafür nicht mehr die Trunk brauche.