TMemIniFile: Vorteile, Nachteile, Einschränkungen

[himitsu]

Es gibt auch irgendeinen "Nachfahren" von INI.

Hab nur dessen Namen vergessen. Wobei ich mir fast sicher bin, dass es mehrere Varianten/Implementationen von sowas gibt.
Da hatte irgendjemand eine Klasse geschrieben, die ähnlich einer INI, bzw. StringList (Name=Value) arbeitet, aber zusätzlich eine Text-Einrückung beachtet.
Da hat man dann eine Liste ähnlich eine einfachen XML/JSON, die aber mehr wie eine INI aussieht.

Ich glaub von Python kenn man auch sowas, wo Verschachtelungen über die Einrückung definiert werden und nicht mit Steuerzeichen/-Befehlen ala { } oder BEGIN END.



Und nein, TMemIniFile hat eigentlich "keine" Begrenzung.
Arbeitet intern mit mehreren TStringList, die intern je ein String-Array haben.

Technische Grenzen für 32-Bit-Anwendung:
- 2 GB RAM
- 2 GB-String-Zeiger-Array, also 2G / 4 Byte - einen kleinen Verwaltungsoffset = maximal mögliche Zeilen pro StringListe

TIniFile arbeiter über die zugehörige INI-WinAPI und ja, da gibt es einen schönen "Overhead".
INI (TIniFile) "hatte" mal eine maximale Dateigröße von 64 KB (Win9x) und die API ist langsam,
vorallem bei "vielen" Einträgen, da für jeden einzelnen ValueZugriff die Datei komplett neu eingelesen/ausgewertet/gespeichert wird.

[greenmile]

Ich bin dieser Tage über einen üblen Bug gestolpert. Ich hatte eine INI Datei, die unlesbare Zeichen (ein Export aus einer mySQL) im Nicht-UTF8 Format enthielt. Die INI hatte ca 1000 Sektionen mit einigen Werten. Alles, was nach dem ersten vorkommen des Nicht-UTF8-Zeichens kam, wurde von TMemIni nicht mehr eingelesen, von TIniFile aber sehr wohl. Im Ergebnis konnte TMemIni nur 250 (oder so) Sektionen einlesen, während TIniFile alles eingelesen hat. Die Zeichen waren nicht im Sektionsnamen enthalten, sondern in einem der Werte.

[p80286]

Zitat von greenmile:

Ich bin dieser Tage über einen üblen Bug gestolpert. Ich hatte eine INI Datei, die unlesbare Zeichen (ein Export aus einer mySQL) im Nicht-UTF8 Format enthielt. Die INI hatte ca 1000 Sektionen mit einigen Werten. Alles, was nach dem ersten vorkommen des Nicht-UTF8-Zeichens kam, wurde von TMemIni nicht mehr eingelesen, von TIniFile aber sehr wohl. Im Ergebnis konnte TMemIni nur 250 (oder so) Sektionen einlesen, während TIniFile alles eingelesen hat. Die Zeichen waren nicht im Sektionsnamen enthalten, sondern in einem der Werte.

Was bedeutet "Nicht-UTF8-Zeichen"?

Schlußfolgerung: D10.x kann nicht mehr mit ANSI/Extended-ASCII umgehen?

Gruß
K-H

[Der schöne Günther]

Das würde mich jetzt aber auch interessieren.

Falsch kodierte Strings meinetwegen. Vielleicht Steuerzeichen im String?

[himitsu]

Was TMemIniFile kann, ist eine andere Sache ... die bassiert auf TStringList und kann beim Laden viele Encodings verstehen.

INI per se gibt es nur als ANSI oder Unicode (UTF-16).
Laut Definition der INI-API von Microsoft.

[Uwe Raabe]

Zitat von p80286:

Schlußfolgerung: D10.x kann nicht mehr mit ANSI/Extended-ASCII umgehen?

TMemInifile verwendet das beim Create angegebene Encoding oder das durch das BOM angegebene oder ANSI, wenn kein BOM vorhanden ist (zumindest unter Windows). Vermutlich war hier aber ein UTF8-BOM vorhanden, es folgten dann aber Zeichen, die im UTF8 nicht vorkommen. Das ist schlichtweg nicht erlaubt und würde vermutlich auch mit älteren Delphi-Versionen nicht richtig funktionieren.

[p80286]

Wenn das der Fall sein sollte, das kann jedem(?) mal passieren, ist das persönliches Pech. Wer ungenießbare Daten produziert, soll sich nicht wundern wenn Programme damit nicht umgehen können.

Gruß
K-H

[Michael II]

Seit Umstellung auf TMemIniFile sehe ich bei einigen Kunden [Computerspiel => Kunden wissen teilweise nix über ihren PC] einen massiven Anstieg von "...kann nicht erstellt werden. Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird." Fehlern, wenn das MemIniFile geschrieben werden soll. Dies geschieht auch bei Memini-Files, welche genau einmal gelesen und einmal geschrieben werden.
Das ist natürlich kein Delphi/Emba Problem, sondern ein "AntivirusScanner-Problem" aber definitiv ein Kostenfaktor, wenn Support pauschal abgerechnet wird.

Wenn beim Schreiben was schief läuft (auch das ist nat. kein Delphi Problem), dann ist ein Teil der Daten oder der Inhalt der ganzen memini weg. (Auch das gab's schon wiederholt bei sehr wenigen Kunden.) Ich speichere deshalb jeweils vor dem Schreiben der Daten mittels SetStrings am Anfang und am Ende der Daten eine Versionsnummer ab und überprüfe beim Laden des MeminiFiles, ob diese Nummern am Anfang und am Ende vorhanden sind. Wenn die Marken vorhanden sind, dann erstelle ich ein Backup der Datei; wenn die Marken nicht vorhanden sind, dann lade ich das Backup.

Falls du die MemIni-Daten beim Beenden deines Programms speicherst, dann solltest du unbedingt daran denken, Windows möglichst am Runterfahren zu hindern, bis die MemIni-Daten auf Platte sind. [Das gilt natürlich generell, wenn du Daten speichern willst... ini-Files sind da aber natürlich toleranter...]

autosave/modified, GetStrings, SetStrings finde ich praktisch.