AW: Vorteile von Records gegenüber Objekten
Ich finde, vieles kann man mit beiden lösen (TObject oder Record).
Der Unterschied bzw. die Eignung ergibt sich dann, wenn man viele dieser Strukturen verwalten will. Bei Records müsste man ein Array of <meinRecord> verwenden. Wobei dann das Handling (Records löschen, hinzufügen etc.) relativ umständlich ist und man mit SetLength(Array, Count) u.d.gl. arbeiten müsste. In so einem Falle würde ich dann TObject bevorzugen, weil dann einfach eine TList genutzt werden kann (mit ihrem gesamten Funktionsumfang). Records verwende ich bei fester Anzahl. Da wird das Array of Record nur einmalig auf die richtige Länge gesetzt und jeder Record kann (z.B) aus eine Ini oder XML eingelesen werden, wobei so ein Record einfach die entsprechenden Methoden (zB. LoadFromXML, SaveToXML) selbst beinhalten kann. Das macht manches einfach einfacher :P |
AW: Vorteile von Records gegenüber Objekten
Ein Nachteil von Records ist sicherlich, das ich die ganze Speicherverwaltung am Hals habe, wenn ich Records in Listen unterbringen will (Siehe VirtualTreeview).
Also GetMem und add Pointer in Liste. Beim Aufräumen freemem nicht vergessen. Peter |
AW: Vorteile von Records gegenüber Objekten
Zitat:
@hanspeter: Ebenfalls nicht, wenn man generische Listen nutzt. |
AW: Vorteile von Records gegenüber Objekten
Zitat:
|
AW: Vorteile von Records gegenüber Objekten
Zitat:
Wenn man die Daten an mehreren Stellen verlinken will, dann kommt man mit Objewkten auch besser, da dort die Zeiger schon eingebaut sind. Bei Objekten muß man den Speicher aber auch überall selber erstellen und diese eventuell auch wieder manuell freigeben. Ein
Delphi-Quellcode:
macht da dann schon mehr arbeit, als ein
Array of TObjekt
Delphi-Quellcode:
.
Array of Record
Einfach ein einziges SetLength und schon sind alle Records vorhanden. |
AW: Vorteile von Records gegenüber Objekten
Zitat:
Also vergesse nicht Stackframe hochzusetzen. Wo ist eigentlich der Stack bei modernen Processoren begrenzt? "Unendlich" Speicherplatz hat man nur auf dem Heap. Peter |
AW: Vorteile von Records gegenüber Objekten
Es werden nur die sttischen Daten auf den Stack gelegt, wie die ganzen Grundtypen (integer und Co.), die kleinen Records und die teilweise schon recht großen statischen Arrays.
Bei dynamischen Arrays liegt ja nur der Zeiger auf'm Stack. nja, ich glaub am Stack haben die nicht viel verändert, aber da man mehr virtuellen RAM zur Vefügung hat, wird man den schon recht hochschrauben können. Aber da es eh nicht sinnvoll ist, den Stack all zu sehr zu belasten, stellt sich diese Frage meistens ja garnicht erst. :angle: |
AW: Vorteile von Records gegenüber Objekten
Vorteil
Delphi-Quellcode:
:
class
* Vererbung (inklusive virtuelle Methoden) * implizite Pointer auf den Heap Vorteil
Delphi-Quellcode:
:
record
* variante Teile * konstante Initialisierung möglich * können anonym deklariert werden * liegen auf dem Stack * schreiben in/lesen aus Datei (falls keine automatisierten Typen verwendet werden) * können Operatoren beinhalten (gilt diese Einschränkung für Klassen noch immer?) => wichtig für Generics Vorteil
Delphi-Quellcode:
(wer sagt, dass die deprecated sind, mag für Delphi recht haben, aber nicht für FPC (erst recht nicht im Compiler selbst :P )):
object
* konstante Initialisierung möglich * liegen auf dem Stack * Vererbung (inklusive virtuelle Methoden) Gruß, Sven |
AW: Vorteile von Records gegenüber Objekten
Zitat:
Zitat:
Wobei von mir ja eine der kleinen Mathe-libs als Beispiel diehnt, wie man ein interface danz nett in einem Record verpackt mit Operatoren versehen könnte. |
AW: Vorteile von Records gegenüber Objekten
Eine Sache, die vllt immer etwas kurz kommt:
Records sind da, um sich eigene Datentypen zu bauen. Zum Beispiel eine Zahl mit unendlich vielen Stellen. Da sie Operatoren besitzen können, kann das komplett transparent passieren. Also kann man sich selbst einen Typen schaffen, der sich genauso natürlich verhält, wie es Integer tut. Außerdem gibt es ab & zu die Notwendigkeit Speicherbereiche exakt abzubilden. Zum Beispiel weil man eine DLL-Funktion aufruft, die Daten in einer genauen Struktur erwartet, oder weil man in ein genau definiertes binäres Dateiformat schreibt. Ansonsten fällt mir jetzt nix ein, für das ein Record tatsächlich, auf die gesamte Projekt-Lebenszeit[1], irgendeinen Sinn macht. Wie ich bereits in einem anderem Thread schrieb: Wer Records benutzt um Objekte oder Entitäten abzubilden, weil er keinen Bock auf Speichermanagement hat, der hat sich für die falsche Laufzeitumgegung entschieden. Denn derjenige will ganz offensichtlich eigentlich eine Umgebung mit Unterstützung für Garbage-Collection verwenden. In Delphi hat man nunmal manuelle Speicherverwaltung für Klassen, und Kalssen sind in Delphi das einzge, was auf Dauer in der Lage ist, Objekte und Abläufe abzubilden. Wer das nicht mag, sollte sich genau überlegen, was das eigentlich für ihn bedeutet, oder ob er sich nicht mit wirklichen OOP anfreunden will. [1] nicht nur bis man die aktuelle Methode geschrieben hat |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:02 Uhr. |
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