Unterschied TMemIniFile 10.2 Tokyo / 10.3 Rio

[AJ_Oldendorf]

Hallo zusammen,
einige Funktionen in TMemIniFile laufen unterschiedlich zwischen 10.2 Tokyo und 10.3 Rio.

z.B. ReadSectionValues und EraseSection

In 10.2 wird immer nur eine Section eingelesen und zurückgeliefert (ReadSectionValues), bei 10.3 Rio wird die komplette IniDatei mit allen Sections zurückgeliefert. EraseSection löscht in 10.2 auch nur eine Section, in 10.3 alle Sections in der Ini Datei.
Problem ist, dass in meiner Ini Datei der Section-Name mehrmals vorkommt. Also mehrere Sections mit dem gleichen Namen.
Gibt es dafür in 10.3 irgendwelche Funktionen, die das gleiche Verhalten wie unter 10.2 liefern oder muss ich mein QT jetzt überall anpassen? Gefunden habe ich so schnell nichts im Sourcecode von 10.3.

[Bernhard Geyer]

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Bei Inidateien gibt es die Regel:

- Jede Sektion darf nur einmal vorkommen.

[AJ_Oldendorf]

ok danke. Dann werde ich das entsprechend anpassen.

[jaenicke]

In 10.3 wurde die Performance deutlich gesteigert. Es wird nun ein Dictionary für die Sektionen usw. benutzt (was die Eindeutigkeit voraussetzt).

Windows selbst hat damals zu Zeiten der massenhaften INI-Dateien dann solche Sektionen mit Indizes versehen, z.B. [Section1], [Section2], ... und dazu gab es zumindest teilweise eine Verwaltungssektion mit der Anzahl.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1422453)

In 10.3 wurde die Performance deutlich gesteigert. Es wird nun ein Dictionary für die Sektionen usw. benutzt (was die Eindeutigkeit voraussetzt).

Da diese eigentlich notwendig ist fallen jetzt manche Nutzungen "auf die Nase"

Zitat:

Zitat von jaenicke (Beitrag 1422453)

Windows selbst hat damals zu Zeiten der massenhaften INI-Dateien dann solche Sektionen mit Indizes versehen, z.B. [Section1], [Section2], ... und dazu gab es zumindest teilweise eine Verwaltungssektion mit der Anzahl.

Wenns so viele Einträge werden sollte man eh XML nehmen.

[Der schöne Günther]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422451)

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Bei Inidateien gibt es die Regel:

- Jede Sektion darf nur einmal vorkommen.

Gibt es diese Regel wirklich? Ich konnte nie irgendwelche Regeln von Irgendjemand finden. Wikipedia sagt bspw:

Zitat:

Duplicate names
Most implementations only support having one property with a given name in a section. The second occurrence of a property name may cause an abort, it may be ignored (and the value discarded), or it may override the first occurrence (with the first value discarded). Some programs use duplicate property names to implement multi-valued properties.

Interpretation of multiple section declarations with the same name also varies. In some implementations, duplicate sections simply merge their properties, as if they occurred contiguously. Others may abort, or ignore some aspect of the INI file.

Quelle
(Hervorhebung durch mich)


Demnach wäre eine Ini-Datei mit mehreren gleichnamigen Sektionen nicht fehlerhaft. Und die Änderung von 10.2 auf 10.3 wäre eine Verhaltensänderung.

[Bernhard Geyer]

Die deutsche Wikipedia sagt das

https://de.wikipedia.org/wiki/Initialisierungsdatei

[Schokohase]

Grundsätzlich geht es (wie fast immer) um die Eindeutigkeit.

Eindeutig muss hier die Kombination aus Sektion und Schlüssel sein, oder welchen Wert würde man von dieser INI erwarten

Code:

[Sektion1]
Schlüssel1=Wert1

[Sektion2]
Schlüssel1=Wert2

[Sektion1]
Schlüssel1=Wert3

wenn man Sektion1 und Schlüssel1 abfragt?

Allerdings sehe ich (logisch) kein Problem, wenn eine Sektion doppelt auftaucht

Code:

[Sektion1]
Schlüssel1=Wert1

[Sektion2]
Schlüssel1=Wert2

[Sektion1]
Schlüssel2=Wert3

ist halt nur unübersichtlich für den menschlichen Betrachter und wäre so schöner und kompakter

Code:

[Sektion1]
Schlüssel1=Wert1
Schlüssel2=Wert3

[Sektion2]
Schlüssel1=Wert2

IMHO Könnte man beim Lesen diese zerfledderten Sektionen berücksichtigen/zulassen.

[Delphi.Narium]

Es gibt viele Implementierungen, die auch mit fehlerhaften INI-Dateien zurecht kommen oder auch fehlerhafte erstellen.

Die Definition dessen, was in INI-Dateien (für gewöhnlich) zulässig ist und was nicht, kann man hier ganz gut nachlesen:

https://github.com/SemaiCZE/inicpp/w...-specification

https://mozilla-services.readthedocs.../confspec.html

https://tech-insider.org/windows/res...0221/1INIW.pdf

[hoika]

Hallo,

Zitat:

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Naja, diese Aussage lasse ich mal unkommentiert.

Ich erinnere an die Einführung von TStringList.StrictDelimiter,
um die alte, "fehlerhafte" (?) Implementierung und vor allem die Anwendungen nicht zu brechen.

Wenn TMemIniFile früher falsch implementiert war, gut (oder auch nicht).
Aber das Verhalten einer Komponente, was sie seit Äonen (*übertreib*) hat, einfach zu ändern, tztz.

[Bernhard Geyer]

Zitat:

Zitat von hoika (Beitrag 1422504)

Hallo,

Zitat:

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Naja, diese Aussage lasse ich mal unkommentiert.

Ich erinnere an die Einführung von TStringList.StrictDelimiter,
um die alte, "fehlerhafte" (?) Implementierung und vor allem die Anwendungen nicht zu brechen.

Wenn TMemIniFile früher falsch implementiert war, gut (oder auch nicht).
Aber das Verhalten einer Komponente, was sie seit Äonen (*übertreib*) hat, einfach zu ändern, tztz.

Wenn man nicht davon ausgeht das sich irgendjemand auf diese fehlerhafte Implementierung verlässt, dann kann man diese m.E. Problemlos einfach so korrigieren.
Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

[Schokohase]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422551)

Zitat:

Zitat von hoika (Beitrag 1422504)

Hallo,

Zitat:

Dann hast du dich bisher auf eine fehlerhafte Implementierung verlassen.

Naja, diese Aussage lasse ich mal unkommentiert.

Ich erinnere an die Einführung von TStringList.StrictDelimiter,
um die alte, "fehlerhafte" (?) Implementierung und vor allem die Anwendungen nicht zu brechen.

Wenn TMemIniFile früher falsch implementiert war, gut (oder auch nicht).
Aber das Verhalten einer Komponente, was sie seit Äonen (*übertreib*) hat, einfach zu ändern, tztz.

Wenn man nicht davon ausgeht das sich irgendjemand auf diese fehlerhafte Implementierung verlässt, dann kann man diese m.E. Problemlos einfach so korrigieren.
Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

Man muss aber noch dazu anmerken, dass

Delphi-Quellcode:

TIniFile

(ein reiner Wrapper der Windows-API-Aufrufe) exakt so funktioniert, wie der TE das wünscht. Diese "fehlerhafte" Implementierung wird also vom OS vorgegeben. Richtiger ist die Rio Implementierung von

Delphi-Quellcode:

TMemIniFile

, allerdings funktioniert diese eben anders als

Delphi-Quellcode:

TMemIniFile

.

[freimatz]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422551)

Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

Wo denn?

Hier steht aber: Note: On Windows, a related object, TMemIniFile, works the same way as TIniFile, but buffers writes in memory to minimize disk access.

[Schokohase]

Zitat:

Zitat von freimatz (Beitrag 1422553)

Hier steht aber: Note: On Windows, a related object, TMemIniFile, works the same way as TIniFile, but buffers writes in memory to minimize disk access.

Für Delphi Rio solltest du in der Dokumentation zu Delphi Rio nachschlagen und da steht das nicht mehr drin.
http://docwiki.embarcadero.com/Libra...es.TMemIniFile

[freimatz]

Dann ist es also doch eine Verhaltensänderung und die ist sogar dokumentiert
Ich finde ein Update sollte kompatibel sein.

[Bernhard Geyer]

Zitat:

Zitat von freimatz (Beitrag 1422553)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422551)

Es steht ja auch an genügend Stellen das Sektionen Eindeutig sein müssen.

Wo denn?

https://github.com/SemaiCZE/inicpp/w...-specification

Wie würdest du mit WinAPI-Mitteln eine Ini-Datei mit mehreren gleichen Sektionen auslesen können?
AFAIK gibt es da keine APIs welche das können würden.

[freimatz]

Hm, guter Aspekt. Allerdings habe ich das folgende so verstanden, also ob das ginge.

Zitat:

Zitat von Schokohase (Beitrag 1422552)

Man muss aber noch dazu anmerken, dass

Delphi-Quellcode:

TIniFile

(ein reiner Wrapper der Windows-API-Aufrufe) exakt so funktioniert, wie der TE das wünscht. Diese "fehlerhafte" Implementierung wird also vom OS vorgegeben. Richtiger ist die Rio Implementierung von

Delphi-Quellcode:

TMemIniFile

, allerdings funktioniert diese eben anders als

Delphi-Quellcode:

TMemIniFile

.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422557)

https://github.com/SemaiCZE/inicpp/w...-specification

Sorry. 1. Würdest Du als Delphi-Entwickler eine Spezifikation raussuchen wenn es schon seit Jahrzehnten funktionierete? 2. Warum sollte gerade die Spezifikation die richtige sein. Die ist ja um Jahrzehnte jünger.
Ich bin eh der Meinung es gibt keine offizielle Ini-Spezifikation, also eine Norm.

[Schokohase]

Also damit wir alle über die gleiche Problematik sprechen:

Delphi-Quellcode:

program MemIniTest;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.Classes,
  System.SysUtils,
  System.IniFiles,
  System.IOUtils;

procedure CheckIniClass(AIniFactory: TFunc<string, TCustomIniFile>);
const
  C_CONTENT = '' + //
    '[S1]' + sLineBreak + //
    'k1=v1' + sLineBreak + //
    '[S2]' + sLineBreak + //
    'k2=v2' + sLineBreak + //
    '[S1]' + sLineBreak + //
    'k3=v3' + sLineBreak + //
    '';
var
  lIni: TCustomIniFile;
  lSectionStrings, lValueStrings: TStrings;
  lKeyIdx: Integer;
  lSection, lKey, lValue: string;
begin
  TFile.WriteAllText('.\test.ini', C_CONTENT);

  lIni := AIniFactory('.\test.ini');
  try
    lValueStrings := TStringList.Create();
    try
      lSectionStrings := TStringList.Create();
      try
        lIni.ReadSections(lSectionStrings);
        for lSection in lSectionStrings do
        begin
          Writeln(lSection, ':');
          lValueStrings.Clear();
          lIni.ReadSectionValues(lSection, lValueStrings);
          for lKeyIdx := 0 to lValueStrings.Count - 1 do
          begin
            lKey := lValueStrings.Names[lKeyIdx];
            lValue := lValueStrings.ValueFromIndex[lKeyIdx];
            Writeln('- ', lKey, ' = ', lValue);
          end;
        end;
      finally
        lSectionStrings.Free();
      end;
    finally
      lValueStrings.Free();
    end;
    Writeln('<EOF>');
  finally
    lIni.Free();
  end;
end;

procedure Main();
begin
  Writeln('TMemIniFile:');
  Writeln;
  CheckIniClass(
    function(AFilename: string): TCustomIniFile
    begin
      Result := TMemIniFile.Create(AFilename);
    end);
  Writeln;
  Writeln('TIniFile:');
  Writeln;
  CheckIniClass(
    function(AFilename: string): TCustomIniFile
    begin
      Result := TIniFile.Create(AFilename);
    end);
end;

begin
  try
    Main();
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;

end.

Unter Tokyo

Code:

TMemIniFile:

S1:
- k1 = v1
S2:
- k2 = v2
S1:
- k1 = v1
<EOF>

TIniFile:

S1:
- k1 = v1
S2:
- k2 = v2
S1:
- k1 = v1
<EOF>

Unter Rio

Code:

TMemIniFile:

S1:
- k1 = v1
- k3 = v3
S2:
- k2 = v2
<EOF>

TIniFile:

S1:
- k1 = v1
S2:
- k2 = v2
S1:
- k1 = v1
<EOF>

[Uwe Raabe]

Das steht in der Doku zu TIniFile und in ähnlicher Form auch noch für Rio, insofern erstmal dort keine Änderung. Da steht aber nirgendwo, daß TMemInifile die fehlerhafte Implementierung der WinApi nachbildet und Microsoft schweigt sich in diesem Punkt eh aus und verweist lieber auf die Registry, wo das schon gar nicht mehr gehen würde.

Insbesondere steht in der Delphi Doku nirgendwo, daß mehrere Sections mit gleichen Namen existieren dürfen. Wäre es so, müsste das Verhalten in diesem Fall irgendwo erläutert werden (z.B. was passiert bei ReadSectionValues? In welche Section wird geschrieben, wenn das Item in keiner existiert?), andernfalls wäre es undefiniert. Undefiniertes Verhalten kann sich allerdings schon mal in einer neuen Version ändern.

Wie Freimatz schon sagte, gibt es keine Norm für diesen Fall, und somit kann sich Delphi auch an keine halten bzw. gehalten haben. Die Änderung des Verhaltens in Rio ist also durchaus plausibel und meiner Meinung nach auch akzeptabel, da sie eine Inkonsistenz beseitigt. Jetzt muss das nur noch irgendwer mal in die Doku aufnehmen.

[Schokohase]

Die größte Überraschung bietet sich wenn man Cross-Plattform entwickelt, denn unter Windows ist

Delphi-Quellcode:

TIniFile

ein Wrapper der WinAPI und bei allen anderen Plattformen ein Alias für

Delphi-Quellcode:

TMemIniFile

.

Und da gibt es eben ab Rio jetzt Unterschiede.

[Bernhard Geyer]

Zitat:

Zitat von Schokohase (Beitrag 1422561)

Also damit wir alle über die gleiche Problematik sprechen:

Kannst du den Fall und dein Testprogramm auf quality.embarcader.com hochlanden/Melden?

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1422566)

Kannst du den Fall und dein Testprogramm auf quality.embarcader.com hochlanden/Melden?

Dazu müsste aber auch eine Aussage zu dem gewünschten Verhalten gehören. Insbesondere gibt das Programm ja weder mit TIniFile noch mit TMemIniFile unter Tokyo den eigentlichen Dateiinhalt korrekt wieder. Die dritte Section (die zweite S1) wird zwar ausgegeben, aber mit dem Inhalt der ersten S1 (warum dann überhaupt), während TMemInifile unter Rio die beiden Sections zusammenfasst. Auch lässt sich in Rio mit TMemIniFile der Wert für ReadString('S1', 'k3', '') auslesen. Das Verhalten von TIniFile und das von TMemIniFile unter Tokyo erscheint mir gerade an diesem Beispiel eher zweifelhaft.

Um das Verhalten zu konsolidieren, würde ich eher eine konsistente Implementierung von TIniFile als Spezialisierung von TMemIniFile auch unter Windows vorziehen.

[Schokohase]

Für das Verhalten von

Delphi-Quellcode:

TIniFile

unter Windows kann Delphi nicht wirklich etwas, das ist das Verhalten der WinAPI.

Aber wie Uwe schon sagte, es bleibt zu klären, wie es denn jetzt funktionieren soll.

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1422574)

Um das Verhalten zu konsolidieren, würde ich eher eine konsistente Implementierung von TIniFile als Spezialisierung von TMemIniFile auch unter Windows vorziehen.

Das hätte auch den Vorteil, dass TIniFile noch funktioniert, falls Microsoft die veralteten Windows 3.x APIs dafür doch mal rauswirft...

Noch sinnvoller wäre aber wohl ein optionaler XML-Adapter oder so um das ganze leicht in ein moderneres Format zu bringen...

[AJ_Oldendorf]

Da habe ich ja eine Diskussion losgetreten ;-)
Ich nutze meine Konstruktion mit TMemIniFile nur zum lesen der Datei, ich speichere darin nichts ab, habe ich mir jetzt einfach die "alte" Variante von TMemIniFile (< 10.3 Rio) nachgebaut und nutze diese Klasse. Damit geht alles wie vorher auch. Übrigens war das Verhalten von TMemIniFile in Tokyo auch das gleiche Verhalten wie in allen Versionen davor auch. Also nicht Tokyo hatte die "falsche" Implementierung sondern Rio ist die erste Version, die es "richtig" macht.
Ob richtig oder nicht, kann sich jeder selber überlegen bzw. es nutzen wie man es eben braucht :-D

[Rollo62]

TMemIniFile basierte auf TStringList (zumindest noch vor Rio).
Hab jetzt nicht gecheckt was genau da in Rio wohl umgebaut worden ist.

Zitat:

Anmerkung: Beim Parameter Name wird nicht zwischen Groß- und Kleinschreibung unterschieden. Die Eigenschaft Values liefert also den Wert des ersten gefundenen Strings, dessen Zeichenkombination (ohne Berücksichtigung der Schreibweise) dem angegebenen Name entspricht.

Wenn ich eine Implementierung einsetze schaue ich auch immer mal kurz unter die Haube, um zu verstehen was da wohl abgeht.
Das mehrere gleiche Sections Probleme machen können sollte auch vom Einsatz der ursprünglichen TStringList als Basis klar gewesen sein.

Wenn das nun unbedingt gebraucht wird, würde ich versuchen das alte Verhalten mit TStringLists in einer eigenen Klasse oder Ableitung nachzubilden.

Rollo

[hoika]

Hallo,

Zitat:

Wenn ich eine Implementierung einsetze schaue ich auch immer mal kurz unter die Haube, um zu verstehen was da wohl abgeht.

Ich benutze OpenSSL, schaue aber nicht unter die Haube, weil es mir zu kompliziert ist;)

Aber Unit-Tests sollten sowas finden (wenn man überhaupt davon ausgeht, das das was schiefgehen kann...)

[Der schöne Günther]

Zitat:

Zitat von hoika (Beitrag 1422636)

Aber Unit-Tests sollten sowas finden (wenn man überhaupt davon ausgeht, das das was schiefgehen kann...)

Wenn man ein paar mal die Erfahrung gemacht hat fängt man tatsächlich an Unit-Tests für die Embarcadero-RTL zu schreiben. Das sollte bei einem mehrere tausend Euro teuren Produkt eigentlich der Hersteller selbst übernehmen aber naja :roll:

[hoika]

Hallo,
wenn die das mit den Unit-Tests nicht machen würden, würde gar nichts nach einem Update funktionieren.
Aber auch das Schreiben von guten Unit-Tests muss gelernt sein.

Aber schön wäre auch mal das Compilieren der IDE mit FastMM4... ;)

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1422636)

Aber Unit-Tests sollten sowas finden (wenn man überhaupt davon ausgeht, das das was schiefgehen kann...)

Das würde voraussetzen, daß das gewünschte Verhalten auch irgendwo beschrieben ist. Unit-Tests finden in der Regel nur Fehler, die man schon mal hatte oder von vornherein ausschließen will. Ich bin mir ziemlich sicher, daß es für TMemIniFile bereits einige Unit-Tests gibt. Allerdings wird vermutlich keiner davon mit mehreren Sections gleichen Namens arbeiten, denn dann wäre diese Problematik ja bewusst und sowohl dokumentiert als auch konsistent implementiert. In diesem Fall ist das Problem also nicht fehlende Unit-Tests, sondern eher das fehlende Bewusstsein für dieses Szenario.

Um nochmal auf das ursprüngliche Verhalten von TMemIniFile anhand des obigen Testprogramms zurückzukommen: Die zweite Section wird zwar bei ReadSections aufgelistet, an ihren Inhalt kommt man aber weder mit ReaadString noch ReadSectionValues ran (gleiches gilt auch für TIniFile). Wozu sollte das zweite Vorkommen dieser Section denn nun überhaupt gut sein? Eigentlich müsste man bei ReadSections diese Doublette doch besser gleich entfernen (oder eine Exception werfen). Dann hat man aber faktisch dasselbe Verhalten, als ob die doppelte Section gar nicht in der INI vorhanden wäre.

In Rio wird dieses Verhalten (bewusst oder unbewusst) geändert in der Art, daß zwar die doppelte Section nicht mehr aufgeführt wird, deren Werte aber jetzt zur Verfügung stehen. Als Nebeneffekt wird beim Schreiben von TMemInifile auch noch implizit eine Normalisierung durchgeführt, bei der die doppelten Sections in einer zusammengefasst werden. Ich finde dieses Verhalten wesentlich realistischer und auch sinnvoller, wobei ich ziemlich sicher bin, daß dies nicht wirklich der Grund für diese Änderung war, sondern es sich eher um einen Nebeneffekt handelt.