Vorteile von Records gegenüber Objekten

[Progman]

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

[hanspeter]

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

[Deep-Sea]

Zitat von Progman:

Bei Records müsste man ein Array of <meinRecord> verwenden.[...] In so einem Falle würde ich dann TObject bevorzugen, weil dann einfach eine TList genutzt werden kann [...]

Records kann man auch in Listen verwalten - erst recht in generischen?!


@hanspeter:
Ebenfalls nicht, wenn man generische Listen nutzt.

[s.h.a.r.k]

Zitat von hanspeter:

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

Für sowas würde ich auf jedenfall Klassen verwenden. Wobei das immer auf die Architektur im Hintergrund ankommt. In dem Fall: DataManager enthält alle Datenobjekte, dann gibts ein FilterManager, der dem VST/VDT/VTV dann nur die passenden anbietet und so eben nur eine Referenz darauf bekommt. Um die Freigabe muss sich der DataManager kümmern.

[himitsu]

Zitat von Progman:

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.

TList<> , die Generische


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 Array of TObjekt macht da dann schon mehr arbeit, als ein Array of Record .
Einfach ein einziges SetLength und schon sind alle Records vorhanden.

[hanspeter]

Zitat von himitsu:

Ein Array of TObjekt macht da dann schon mehr arbeit, als ein Array of Record .
Einfach ein einziges SetLength und schon sind alle Records vorhanden.

Ich meine das, zumindest in einer Procedure die Records auf dem Stack angelegt werden.
Also vergesse nicht Stackframe hochzusetzen. Wo ist eigentlich der Stack bei modernen Processoren begrenzt? "Unendlich" Speicherplatz hat man nur auf dem Heap.

Peter

[himitsu]

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.

[JamesTKirk]

Vorteil class :
* Vererbung (inklusive virtuelle Methoden)
* implizite Pointer auf den Heap

Vorteil 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 object (wer sagt, dass die deprecated sind, mag für Delphi recht haben, aber nicht für FPC (erst recht nicht im Compiler selbst )):
* konstante Initialisierung möglich
* liegen auf dem Stack
* Vererbung (inklusive virtuelle Methoden)

Gruß,
Sven

[himitsu]

Zitat von JamesTKirk:

* können Operatoren beinhalten (gilt diese Einschränkung für Klassen noch immer?)

Das wird und kann sich auch nicht ändern.

Zitat von siehe Beitrag #9:

Bei Objekten geht sowas aber nicht (niemals, also nicht ohne soeinen komischen Garbage-Collector)

Wie gesagt, für Interfaces wäre es eigentlich möglich.
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.

[Elvis]

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