Ansistring , shortstring

[Uwe Raabe]

Zitat von Redeemer:

Ich habe diverse Records aus relativ kurzen Strings, die Schlüssel von TDictionary sein können. Aus dem Grund muss ich ShortString benutzen.

Diese Schlussfolgerung verstehe ich jetzt nicht. Wieso musst du dazu ShortString benutzen? Weder relativ kurze Strings noch Schlüssel von TDictionary implizieren ShortString. Eigentlich ist das Gegenteil der Fall.

[Redeemer]

Zitat von Uwe Raabe:

Zitat von Redeemer:

Ich habe diverse Records aus relativ kurzen Strings, die Schlüssel von TDictionary sein können. Aus dem Grund muss ich ShortString benutzen.

Diese Schlussfolgerung verstehe ich jetzt nicht. Wieso musst du dazu ShortString benutzen? Weder relativ kurze Strings noch Schlüssel von TDictionary implizieren ShortString.

Aber wenn ich Strings in einen Record packe. TDictionary scheint die TKeys zu hashen, also muss in gleichen Keys auch exakt das gleiche drinstehen. Daher auch ZeroMemory, denn sonst steht hinter den Nutzdaten noch Blödsinn. Einfache WideStrings hingegen sieht TDictionary nicht als die Pointer an, die sie eigentlich sind, und kann erkennen, wenn zwei TKeys gleich sind.
Kurze Strings nur als Hinweis, damit niemand befürchtet, mein Speicher könnte nicht reichen. Abgebildet werden bei mir nvarchar(20).

[Uwe Raabe]

Zitat von Redeemer:

Abgebildet werden bei mir nvarchar(20).

Ich hätte jetzt spontan string genommen. Das erschlägt das Unicode (n) und die variable Länge (var). Der Hash geht immer nur über die aktuelle Länge und gleiche Inhalte ergeben somit denselben Hash. ShortString wäre mir nicht mal als allerletzte Möglichkeit in den Sinn gekommen. Oder machst du mit den Records noch irgendwas, von dem wir hier noch nichts wissen?

[himitsu]

Ja, der Speicher des Records TKey wird da direkt verglichen, was aber kein Grund sein muß, denn nicht umsonst kann man dem Dictionary einen eigenen Comparer geben und darin auch gern jegwelche Optimierungen integrieren.

[Redeemer]

Zitat von himitsu:

Ja, der Speicher des Records TKey wird da direkt verglichen, was aber kein Grund sein muß, denn nicht umsonst kann man dem Dictionary einen eigenen Comparer geben und darin auch gern jegwelche Optimierungen integrieren.

Guter Einwand. Kann man machen.

Zitat von Uwe Raabe:

Zitat von Redeemer:

Abgebildet werden bei mir nvarchar(20).

Ich hätte jetzt spontan string genommen. Das erschlägt das Unicode (n) und die variable Länge (var). Der Hash geht immer nur über die aktuelle Länge und gleiche Inhalte ergeben somit denselben Hash. ShortString wäre mir nicht mal als allerletzte Möglichkeit in den Sinn gekommen. Oder machst du mit den Records noch irgendwas, von dem wir hier noch nichts wissen?

Delphi-Quellcode:

type
  TTest = record
    Text: string;
    Zahl: Integer;
  end;

procedure TuWas();
var
  Wert1, Wert2: TTest;
  TestDictionary: TDictionary<TTest, Boolean>;
begin
  Wert1.Zahl := 4711;
  Wert1.Text := 'wupdi';
  Wert2.Zahl := 4711;
  Wert2.Text := 'wupdi';
  TestDictionary := TDictionary<TTest, Boolean>.Create();
  try
    TestDictionary.Add(Wert1, False);
    TestDictionary.Add(Wert2, False); // Sollte fehlschlagen, tut es aber nicht!
  finally
    TestDictionary.Free();
  end;
end;

[Uwe Raabe]

Ach so! Du verwendest den ganzen Record als Key. Das hatte ich nicht so verstanden. Hätte ich auch nicht so gemacht, sondern den Hinweis von Frank mit dem Comparer umgesetzt. Das erscheint mir als deutlich sauberer und wartbarer.