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?