Vorteile von Records gegenüber Objekten

[Luckie]

Das ist keine negative Haltung. Ich habe nur das Stilmittel der Provokation in der Diskussion eingebracht.

Aber bisher wurden nur Vorteile von Records genannt. Wobei ich den Beitrag von himitsu nicht so ganz verstanden habe.

[Deep-Sea]

Zitat von Luckie:

Aber bisher wurden nur Vorteile von Records genannt.

Wolltest du doch auch wissen, oder?!
Großer Nachteil von Records im Vergleich zu Objekten: Keine Vererbung.

[himitsu]

Zitat von Deep-Sea:

Großer Nachteil von Records im Vergleich zu Objekten: Keine Vererbung.

Und keine Referenzen/Referenzzählung ... wobei das auch ein Vorteil sein könnte.

Zitat von WladiD:

Nachteile?: Keine automatischen Konstruktoren (Kann auch als Vorteil gesehen werden)

Die hab ich vor Jahren schon bei Emba beantragt, es wäre ein Leichtes diese zu integrieren (hab denen sogar gesagt wie),
aber die hören ja nie auf mich.

[s.h.a.r.k]

Zitat von Luckie:

Das ist keine negative Haltung. Ich habe nur das Stilmittel der Provokation in der Diskussion eingebracht.

Aber bisher wurden nur Vorteile von Records genannt. Wobei ich den Beitrag von himitsu nicht so ganz verstanden habe.

Ich glaube, es hatte sich da ein kleiner Fehler eingeschlichen, oder? (rot = meine Verbesserung)

Zitat von himitsu:

Nja der Hauptgrund für ObjekteRecords ist die automatische Speicherverwaltung.
Records werden automatisch initialisiert, kopiert und finalisiert. (jedenfalls bei entsprechenden enthaltenen Typen, bei welchen sowas gemacht wird, wie DynArrays, Strings und Interfaces)

[Luckie]

Darüber bin ich auch gestolpert. Na ja, ich wollte den Unterschied wissen, also eine Gegenüberstellung. Dazu gehören natürlich auch Vorteile von Objekten gegenüber Records.

[s.h.a.r.k]

Ich denke, dass wenn man simple Datenstrukturen hat und dazu Methoden programmieren will, dann kann man Records hier sehr gut verwenden. Vor allem wenn man generische Methoden schreiben will brauch man entweder einen Record oder eben eine Klasse. Normalen Proceduren/Funktionen kann man das ja leider nicht beibringen. Wenn es dann etwas mehr Logik + Vererbung + Kapselung brauch habe Klassen schon einige Vorteile. Wie heißt es immer so schön: kommt ganz drauf an

[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

[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.

[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

[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.