Ansistring , shortstring

[himitsu]

Nja, der AnsiString-Cast ist ja nicht unbedingt nötig.
Der unterdrückt nur die Compilerwarnung vonwegen "möglichem" Datenverlust aufgrund Unicode-nach-ANSI.


Karkein String[x] aka ShortString verwenden und auch keine AnsiString mehr,
denn jemand kam auf die grandiose Idee in NextGen-Compilern das ANSI zu verbieten.
(intern verwendet es Delphi selbst noch, weil es Ohne einfach nicht "gut" geht, aber öffentlich sind die Typen nicht mehr direkt verfügbar)

Es gibt quasi nur noch Unicode und der Rest mit Byte-Arrays und TEncoding.

https://www.delphipraxis.net/181902-...droid-app.html
https://stackoverflow.com/questions/...ier-ansistring




SetString und Dergleichen gibt es so ja nicht für den alten ShortString.

[Redeemer]

Ich habe diverse Records aus relativ kurzen Strings, die Schlüssel von TDictionary sein können. Aus dem Grund muss ich ShortString benutzen. Damit ich trotzdem eine vollständige Unicode-Unterstützung habe, mache ich das so:

Delphi-Quellcode:

uses
  Windows;

type
  TMixed = record
    private
      procedure SetText(const Value: string);
      function GetText(): string;
      var
        FText: ShortString;
    public
      property Text: string read GetText write SetText;
      var
        Zahl: Integer;
  end;

procedure TMixed.SetText(const: Value: string);
begin
  ZeroMemory(@FText, SizeOf(ShortString);
  FText := UTF8Encode(Value);
end;

function TMixed.GetText(): string;
begin
  Result := UTF8ToWideString(FText);
end;

Das klappt nur mit WideStrings mit Length(UTF8Encode()) < 256 als notwendiger Bedingung.
Man könnte auch als hinreichende Bedindung prüfen, ob sie maximal 63 Zeichen Länge oder maximal 85 Length() haben (je nachdem, was zuletzt eintritt, sprich ein WideString mit Length()=120 ist OK, wenn es weniger als 63 Zeichen sind, aber die Anzahl der Zeichen in einem String zu bestimmen muss man jetzt auch nicht machen).

[p80286]

Wird da nicht etwas Verschluckt?
@Ftext ist ja nicht das gleiche wie @Ftext[1] !

Gruß
K-H

[himitsu]

Doch, beim ShortString ist es "erstmal" der richtige Speicher, da hier kein Pointer im Typ steckt,
aber hier ist das erste Byte/Zeichen, die berühmte [0], das Längenbyte.

Zur Fehlerprävention würde ich aber auch hier immer mit @FText[0] arbeiten, bzw. [1] und SizeOf-1,
Für den erzeugten Binärcode hat es praktisch keine Auswirkung, aber besser immer machen und dann nicht einmal ausversehn bei den LongStrings vergessen.

Das ZeroMemory sorgt am Ende auch nur dafür, dass der speicher hinter dem String Text mit 0 gefüllt ist.
ShortStrings haben standardmäßig auch keine abschließende #0, da hier ausschließlich das LängenByte gilt und der ungenutzte Speicher "kann" unbestimmt/zufällig sein.

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