Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Record Verwalten - Wie am besten ? (https://www.delphipraxis.net/160210-record-verwalten-wie-am-besten.html)

dataspider 3. Mai 2011 09:50

AW: Record Verwalten - Wie am besten ?
 
Liste der Anhänge anzeigen (Anzahl: 1)
bei einer RecordList musst du dich IMHO um den Speicher kümmern.
Ich habe mal ein Beispiel angehangen.

Frank

himitsu 3. Mai 2011 10:05

AW: Record Verwalten - Wie am besten ?
 
Zitat:

Zitat von dataspider (Beitrag 1098504)
bei einer RecordList musst du dich IMHO um den Speicher kümmern.
Ich habe mal ein Beispiel angehangen.

Frank

Zum Glück gibt es inzwischen (seit D2009) auch noch die generische TList<>, welche da vieles vereinfacht. :angle2:
(auch wenn dieses eine kleine und manchmal gemeine Einschränkung besitzt, was das nachträgliche Ändern eines Recordinhaltes betrifft :wall: )

Und was den Ausgangsrecord dieses Threads betrifft:
Delphi-Quellcode:
TDictionary<Handle, String>
, mit Handle als Key und String als Value (oder andersrum).

taveuni 3. Mai 2011 10:40

AW: Record Verwalten - Wie am besten ?
 
Der Vollständigkeit halber noch die sich an Bord befindende
THashedStringlist.

Elvis 3. Mai 2011 10:55

AW: Record Verwalten - Wie am besten ?
 
Zitat:

Zitat von BUG (Beitrag 1098434)
Klingt irgendwie nach einem Dictionary, besonders wenn du denn Index nur zum Durchlaufen brauchst.

+1
Alzaimars Klassen sind alles andere als "fett". Wer seine Beiträge kennt, weiß wie wichtig ihm Performance ist.
Und seine kleinen Hashlisten sind mehr zackig genug. Wenn du Zugriff zu neueren Delphis hast, kannsu dir TDictionary<int, String> ankieken.
Bis dahin ist sein TIntegerDictionary so ziemlich das wassu willst.
Zitat:

Zitat von himitsu (Beitrag 1098511)
Zum Glück gibt es inzwischen (seit D2009) auch noch die generische TList<>, welche da vieles vereinfacht. :angle2:
(auch wenn dieses eine kleine und manchmal gemeine Einschränkung besitzt, was das nachträgliche Ändern eines Recordinhaltes betrifft :wall: )

Records sind Werte, keine Objekte und erst recht keine "Entitäten". Und in fast jedem Fall sollten Werte unveränderlich sein. Will heißen, dass eine Änderung eine veränderte Kopie liefern sollte. Nur so ist klar was unter der Haube tatsächlich passiert.

Delphi-Quellcode:
var x, y TDeinRecord;
begin
  x.Abc := 1;
  y := x;
  x.Abc := 2
  Assert(y.Abc = 2, 'Ja y.Abc = 1, denn y hat bekam ja auch eine KOPIE, so arbeiten reine *Werte* nunmal.');
end;
http://stackoverflow.com/questions/441309/why-are-mutable-structs-evil
Wer Records als Objekte missbraucht, weil er keinen Bock auf Speicherverwaltung hat, hat die falsche Laufzeitumgebung gewählt.

shmia 3. Mai 2011 13:00

AW: Record Verwalten - Wie am besten ?
 
Nochmals Entscheidungshilfe Record vs. Klasse innerhalb von Listen

Record
* bei sehr einfachen Strukturen wie z.B. TPoint oder Vektoren die in hoher Anzahl
(z.B. 3D Gittermodell) benötigt werden
Records benötigen geringfügig weniger Speicherplatz (4Bytes) als Objekte, was bei Stückzahlen im Millionenbereich eine Rolle spielen kann
* bei Records die von Aussen vorgegeben fest werden (z.B. Records der Windows API, Records einer Datei)

Klasse
* der Standardweg ist, dass man Datenstrukturen als Klassen abbildet
* die Klassen sollten nicht nur Properties haben, sondern auch Methoden, die mit den Daten arbeiten
* Programme, die mit Arrays oder Listen von Records arbeiten, verwenden implizit auch Code, der mit den Daten des Records arbeitet.
Nur ist dieser Code unkontrolliert in der Anwendung verschmiert, während bei einer Klasse der Code in Methoden klar erkennbar (und testbar!) wird.

==> In 95% der Fälle wird man sich für eine Klasse als Datenkontainer entscheiden.


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:23 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz