TMemIniFile: Vorteile, Nachteile, Einschränkungen

[Glados]

Mich interessiert es brennen, ob man mit TMemIniFile eine maximale Anzahl an Sections einlesen kann oder ob man ohne Weiteres 1000 einlesen und auch wieder abspeichern kann?
Intern arbeitet eine StringListe, deswegen sehe ich da keine Probleme. Aber gibt es dennoch eine Grenze an die man stoßen könnte?

Gibt es irgendwelchen anderen Nachteile: Dass TMemIniFile gegenüber TIniFile klar schneller ist, das sollte klar sein.
Aber soweit ich weiß wird beim einlesen einer einzigen Ident immer die gesamte Datei eingelesen was man ggf. als "Overhead" bezeichnen könnte? :?:

Die Lesbarkeit ist hier sehr gut wie ich finde, nicht zu vergleichen mit JSON.
Außerdem kann bei Ini der Nutzer selber Daten abändern, ohne erst ein Meister in Dechiffrierung sein zu müssen (JSON).

[jaenicke]

Deutlich besser lesbar und manuell editierbar als JSON und deutlich flexibler und moderner als INIs wären XML-Dateien. Die kann man auch deutlich einfacher manuell anschauen und modifizieren, da man dort eine hierarchische Organisation hat, die man beim Editieren auch einzeln ein- und ausklappen kann.

Noch dazu gibt es dort Features um direkt bestimmte Einträge herauszufiltern (XPath) usw.

Aber vor allem kann man die Einträge viel besser gruppieren und hat nicht nur eine lange Liste von Sektionen usw., die manchmal in INIs dann sogar zur Abbildung von hierarchischen Strukturen missbraucht wurde.

Eine direkte Größenbeschränkung gibt es bei TMemIniFile nicht, aber die Performance ist deutlich schlechter als bei ähnlich großen XML-Dateien. TIniFile wiederum setzt auf API-Funktionen aus Windows 3.x auf und hat auch einige Bugs daraus geerbt...

[Der schöne Günther]

XML deutlich flexibler, ja. Besser lesbar als JSON oder gar Ini? Sicher nicht.

Eine ini-Datei traue ich noch zu jedem nicht technisch Versierten (Vertreter, Vertriebler, Kunde selbst) anzupassen. Im Notfall macht er den Identifier und damit einen Wert kaputt. Bei XML oder JSON schrotte ich mit etwas Pech gleich die gesamte Struktur.

[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.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1376972)

XML deutlich flexibler, ja. Besser lesbar als JSON oder gar Ini? Sicher nicht.

Bis jetzt hat jeder, der sich weniger auskannte, dem ich erklären musste wie er da etwas ändert, das Gegenteil gesagt.
Mit JSON ist da kaum jemand klargekommen, XML und Ini waren beide kein großes Problem.

Einen passenden Editor setze ich mal voraus... mit Notepad sind alle drei Formate nicht schön editierbar, wenn es um größere Datenmengen geht.

[himitsu]

INI ignoriert einfach alles, was es nicht kennt (was falsch ist).

Hat den Vorteil, dass beim Bearbeiten mit TextEditor (eventuell inkl. Syntax-Highlighter) nicht gleich alles knallt, nur weil bei einem Wert irgendwas nicht stimmt.

[Rollo62]

+ keine 64K Grenze
+ keine mir bekannten Grenzen
+ Unicode möglich
+ Vermutlich schneller, habs nicht gecheckt
+ Alles was ich an TStringGrid mag
+ Doppelte Einträge möglich unter gleichem Namen (würde ich aber nie machen)
+ MultiPlatform
+ Portierung TIniFile zu TMemIniFile ist ein Spaziergang
- Liegt wohl zu 100% im Memory, bei IniFile bin ich mir nicht sicher

Wenn einer IniFile sagt denke ich vollautomatisch an TMemIni, ohne Ausnahme.

Rollo

[himitsu]

TIniFile kann auch Unicode.
Und die 64K gibt es auch seit vielen Jahren nicht mehr.

WritePrivateProfileSection

Zitat:

If the file exists and was created using Unicode characters, the function writes Unicode characters to the file. Otherwise, the function creates a file using ANSI characters.

[p80286]

Zitat:

Zitat von Der schöne Günther (Beitrag 1376972)

Eine ini-Datei traue ich noch zu jedem nicht technisch Versierten (Vertreter, Vertriebler, Kunde selbst) anzupassen. Im Notfall macht er den Identifier und damit einen Wert kaputt. Bei XML oder JSON schrotte ich mit etwas Pech gleich die gesamte Struktur.

Wenn er recht hat, hat er recht.

Zitat:

Zitat von jaenicke (Beitrag 1376979)

Einen passenden Editor setze ich mal voraus... mit Notepad sind alle drei Formate nicht schön editierbar, wenn es um größere Datenmengen geht.

Da übersiehst Du, das der eine oder andere Editor, etwas blind ist.
Da geht dann kein Weg mehr an Notepad vorbei.

Meiner Meinung nach haben alle drei Formate ihre Berechtigung, allerdings bin ich bisher erst einmal in die Verlegenheit gekommen die 64KGrenze (die es nicht mehr gibt) zu beachten, und das nur weil ich damals weder XML noch JSON gekannt habe.

Gruß
K-H

[Luckie]

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1376996)

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

Das ist die Moderne Ableitung von "Wie mache ich einen Thread runter" ;)

gruss

[OlafSt]

Habe ich nicht sogar hier gelesen, das TIniFile eine Reihe Bugs "geerbt" hat, weil es die WinAPI-Funktionen benutzt ? Und das man besser TMemIniFile benutzt, weil dies komplett neu geschrieben wurde, ohne WinAPI-Funktionen ?

Abgesehen von einem

Delphi-Quellcode:

TMemIniFile.Update;

, das beim Schreiben einer Ini-Datei ausgeführt werden muß, ist der Unterschied zum Original TIniFile gleich null. Meine Empfehlung ist daher klar TMemIniFile.

Man sollte es nur nicht übertreiben, manche Konfigurationen (soferm man sowas dann noch so nennen kann) gehören dann doch besser in XML oder JSON und sind dann meist auch so komplex, das der "Vertriebsmann" oder "die Sekretärin" da eh nix mehr dran ändern würde.

[bra]

Um mal meinen Senf dazuzugeben:
Ehe man den Benutzer (Endanwender) in einer Konfigurationsdatei (ob ini, xml oder sonstwas) rumpfuschen lässt, sollte man lieber eine vernünftige Oberfläche für die Einstellungen bereitstellen.

[Rollo62]

Wenn ich komplexe Strukturen brauche dann XML oder JSON,
ansonsten ist bei kleinen, simplen Speicherdaten doch nichts gegen INI Files zu sagen.
Warum dann immer mit Kanonen auf Spatzen ... ?
Muss halt jeder selber wissen.

Rollo

[Glados]

Zitat:

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

Ist doch nicht schlimm :-D

Zitat:

Abgesehen von einem TMemIniFile.Update; , das beim Schreiben einer Ini-Datei ausgeführt werden muß, ist der Unterschied zum Original TIniFile gleich null

Eine Interposer-Klasse mit überschriebenem Destroy, wo man Update selber aufruft, hilft hier.

[freimatz]

Zitat:

Zitat von Luckie (Beitrag 1376996)

Er hat nach Vor- und Nachteilen von TMenIniFile gefragt. Warum empfehlt ihr im jetzt XML und JSON?

Nun ja ... JSON hat er selbst ins Spiel gebracht. :)
Und Kathinkas Law gilt auch hier.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1377014)

Zitat:

Abgesehen von einem TMemIniFile.Update; , das beim Schreiben einer Ini-Datei ausgeführt werden muß, ist der Unterschied zum Original TIniFile gleich null

Eine Interposer-Klasse mit überschriebenem Destroy, wo man Update selber aufruft, hilft hier.

Oder man setzt das

Delphi-Quellcode:

AutoSave

, das es seit Delphi 10.1 Berlin gibt. Zusammen mit dem ebenfalls dort eingeführten

Delphi-Quellcode:

Modified

schreibt es nämlich nur dann, wenn sich etwas geändert hat.

[freejay]

Also ich verwende (einen Nachfahren von) TMemIniFile beim Lesen und das "normale" TIniFIle beim Schreiben.

Warum?

TMemIniFile ist beim Lesen viel schneller (wenn man die Datei nicht für jeden zu lesenden Wert neu öffnet...).

TIniFile zerstört mir beim Schreiben nicht die Formatierungen und Kommentare in der INI-Datei, die man möglicherweise zur besseren Übersicht beim manuellen Bearbeiten angelegt hat.

Mir sonst noch bekannter Unterschied zwischen beiden:

Die beiden Units behandeln in Hochkommas gesetzte Werte unterschiedlich: TIniFile schmeißt die Hochkommas einfach weg (wenn der Wert mit " anfängt und aufhört), TMemIniFile tut das nicht.

Was die beiden sonst noch so trennt weiß ich nicht...

[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:

Zitat von greenmile (Beitrag 1377067)

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:

Zitat von p80286 (Beitrag 1377078)

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.