![]() |
dynmisches array statt TArray<T>?
Hallo,
welche Nachteile hat es TArray<T> zu nehmen statt dynamische Array, also "array of"? Bei Stackoverflow gibt es schon diese Frage unter: ![]() 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. |
AW: dynmisches array statt TArray<T>?
Zitat:
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. |
AW: dynmisches array statt TArray<T>?
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. |
AW: dynmisches array statt TArray<T>?
Funktionell ist es das "Gleiche".
Nur die Ausnahme mit dem Methoden-Parameter, wo
Delphi-Quellcode:
eine andere Bedeutung besitzt. (OpenArray)
array of
Aber bei der Kompatibilität hat DynArray mit
Delphi-Quellcode:
einen Unterschied zum generischen
array of T
Delphi-Quellcode:
.
TArray<T>
Denn der Generic wird Programmweit "identisch" als "eine" Typdeklaration behandelt, wärend jedes
Delphi-Quellcode:
je ein "eigener" Typ wird.
array of T
|
AW: dynmisches array statt TArray<T>?
Und das ist ein Nachteil? :gruebel:
|
AW: dynmisches array statt TArray<T>?
Zitat:
Delphi-Quellcode:
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.
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. 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. |
AW: dynmisches array statt TArray<T>?
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz