Ja, ThreadVar ist ein Sonderfall, aber bei allem Anderen werden gemanagte Typen ordentlich behandelt.
Aufpassen muß man z.B. wenn man Speicher für Records, oder so, via GetMem/FreeMem und Co. holt/freigibt.
Aber New/Dispose beachten sowas.
ThreadVar:
In der Hilfe wird zwar Einiges gesagt, aber das auch nicht ganz Richtig und Vieles fehlt komplett (z.B. was man dort besser nur mit viel Vorsicht verwenden sollte, oder besser garnicht, also was man da am Ende selber Freigeben muß).
Außerdem wäre es nett, wenn hier der Compiler bereits eine Warnung für solche Typen werfen würde, denn er weiß ja welches ein gemanagter Typ ist, bzw. Pointer allgemein
(wo er nicht weiß, ob es nur auf was Anderes zeigt, oder ob der Entwickler dort Selbsterstelltes reintun wird).
Bei Strings/Interfaces/Objekten/Variants/DynArrays/... würde z.B. gern ein Speicherleck entstechen, wenn der Programmierer es nicht freigibt, denn Delphi/Windows macht es nicht automatisch, beim Ende des Threads,
also wäre es besser sowas besser nicht zu verwenden.
Zitat:
Bei Zeigern und Funktionen ist diese Art der Deklaration nicht möglich. Typen, bei denen ein Schreibzugriff einen Kopiervorgang impliziert, wie lange Strings, können nicht als Thread-Variablen deklariert werden.
Das stimmt so nicht ganz -> Doch, kann man.
Die Referenzzählung ist thread-save, auch was den "Kopiervorgang" betrifft, denn erst wird referenzgezählt (beim Schreibzugriff auf Unique geändert) und dann in die "eine" eigene Referenz geschrieben.
Ganze Strings zuweisen geht ohne Probleme, was hängen könnt, wäre z.B. wenn man via PChar/Pointer drauf zugreift, bzw. einzelne Chars über den Arrayzugriff auslesen will (schreiben geht, bei LongStrings, aber nicht bei DynArrays).
Bei DynArrays gibt es leider kein Copy-on-Write, was das Ändern einzelner Felder etwas unpraktisch macht, wenn man das Array nicht vorher selber "unique" macht.
Strings mit Pointerzugriff könnte man vorher via
UniqueString explizit absichern, was aber beim Cast mit PChar meistens bereits automatisch gemacht wird.