dynmisches array statt TArray<T>?

[freimatz]

Hallo,
welche Nachteile hat es TArray<T> zu nehmen statt dynamische Array, also "array of"?

Bei Stackoverflow gibt es schon diese Frage unter: What are the reasons to use TArray<T> instead of Array of T?

Aber die ist auch schon wieder über 7 Jahre her und ich fand dort keinen Nachteil. (Der Aspekt mit array of bei Methoden-Parameter gilt hier nicht weil das offene array Parameter sind und nicht dynamische Arrays.)

Ich könnte mir allenfalls vorstellen dass TArray<T> etwas langsamer beim compilieren ist, sollte aber kaum ins Gewicht fallen.

[dummzeuch]

Zitat von freimatz:

Hallo,
welche Nachteile hat es TArray<T> zu nehmen statt dynamische Array, also "array of"?

TArray<T> gibt es "erst" seit Delphi 2009. Seit wann sie halbwegs zuverlässig funktionieren, weiß ich nicht.

Das dürfte für die meisten Anwendungen inzwischen wohl egal sein, außer wenn man z.B. eine Bibliothek oder einen Experten entwickelt / pflegt, der auch zu alten Delphi-Versionen kompatibel sein soll.

Dann gab es noch das Problem, dass jede Menge Code dupliziert (und auch compiliert wurde), so dass die Executables größer waren. Auch da weiß ich nicht, in wie weit das noch zutrifft.

[freimatz]

Nach meiner Einschätzung arbeitet das zuverlässig, was nicht gleichbedeuted ist mit "so wie man es erwartet".

Zur Erinnerung: "TArray<T> = array of T;"

Das mit der Bibliothek ist richtig. Für mich gerade nicht relevant.

Das mit dem duplizierten Code wurde auf Stackoverflow angesprochen, tritt hier auf wird dort geschrieben.

[himitsu]

Funktionell ist es das "Gleiche".

Nur die Ausnahme mit dem Methoden-Parameter, wo array of eine andere Bedeutung besitzt. (OpenArray)


Aber bei der Kompatibilität hat DynArray mit array of T einen Unterschied zum generischen TArray<T> .
Denn der Generic wird Programmweit "identisch" als "eine" Typdeklaration behandelt, wärend jedes array of T je ein "eigener" Typ wird.

[freimatz]

Und das ist ein Nachteil?

[Dennis07]

Zitat von freimatz:

Und das ist ein Nachteil?

Das kommt darauf an, was du als "Nachteil" siehst.

Delphi-Quellcode:

type
  TArray1 = array of String;
  TArray2, TArray3 = array of String;
  TArray4 = TArray<String>;
  TArray5 = TArray<String>;
begin
  TypeInfo(TArray1) = TypeInfo(TArray2) // Ergibt False
  TypeInfo(TArray2) = TypeInfo(TArray3) // Ergibt True
  TypeInfo(TArray4 {oder: 5}) = TypeInfo(TArray1 {oder: 2 oder: 3}) // Ergibt False
  TypeInfo(TArray4) = TypeInfo(TArray5) // Ergibt Tue
end.

Meiner Meinung nach sollte man eigentlich in modernen Anwendungen immer TArray<T> benutzen, außer es gibt einen wirklich guten Grund es nicht zu tun.
Der "einzige" Grund meiner Meinung nach sind hier offene Array-Parameter, denn die können halt auch staische Arrays entgegennehmen, was ein dynamischer Array-Parameter nicht kann.

Delphi-Quellcode:

//Grundsättzlich gilt, dass...
var Strs: TArray<String>;
// ...immer gleichbedeutend mit...
type TStrs = TArray<String>;
var Strs: TStrs;
//...und mit...
type TStrs = array of String;
var Strs: TStrs;
// ...ist, ohne Ausnahmen.
// Voraussetzung hierfür ist, dass alle Variablen immer den gleichen Typen benutzen.

[himitsu]

Manchmal will man absichtlich unterschiedliche, nicht zuweisungskompatible Typen haben,
z.B. wenn du eine überladene Methode für zwei solcher Typen hast.


Aber ansonsten ist es super, weil du überall ein TArray<Byte> oder TArray<string> schreiben kannst,
und dieser Typ auch mit Typen und Methoden in anderen Units (vorallem Fremdkomponenten) kompatibel ist.

Beispiel TBytes von Delphi vs. dem absolut inkompatiblen Bytes-Array von Indy.
Oder lange Zeit das TStringDynArray von Delphi, was inzwischen als TArray<string> deklariert ist.

Für String und Byte hat Delphi schon ewig vordefinierte Array-Typen, welche aber nicht von allen Entwicklern genutzt wurden (z.B. Indy) und man dann Probleme hatte, sowas zwischen zwei Komponenten/Codes durchzureichen.
Aber für viele Typen gab es auch keine Vordefinierten, womit Jeder seinen eigenen Typen deklarieren musste, welche ohne TArray<T> nicht miteinander arbeiten will.