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.

[himitsu]

Zitat von s.h.a.r.k:

Und das, was du machst und ich gemacht habe, ist quasi eine Vergewaltigung

Wobei Codegear dafür Objekte nutzte (Borland mußte Objekte verwenden),
aber Embarcadero setzt jetzt auch teilweise die Record-Variante ein.

Nja der Hauptgrund für Objekte Records 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)

Records besitzen selber keine Referenzzählung, also wenn man sie kopiert, dann entsteht vom Record wirklich eine Kopie.

Operatoren sind schonmal eine sehr praktische Angelegenheit. (schade daß emba vergessen hat, dieses auch für die Interfaces zur Verfügung zu stellen)
Bei Objekten geht sowas aber nicht (niemals, also nicht ohne soeinen komischen Garbage-Collector)

Und man kann sich sehr schön Datentypen basteln und die zugehörigen Funktionen direkt dort einbauen.
Da geistern vom mir z.b. ein paar knuffige MD5 und SHA1-Varianten durch die DP.


PS: Objekte sind auch nur Pointer, auf aufgemotzte Records und mit ein bissl Vererbung und vollständiger impliziter Dereferenzierung.

[WladiD]

Zitat von s.h.a.r.k:

@WladiD: Wobei das kein Grund für ein record sein muss, da du bei dem was du geschrieben hast auch class nutzen könntest, wobei du dir dann halt die Methoden von TObject einfängst! Habe mich da neulich mal aufklären lassen Eigentlich ist ein Record ja eine Datenstruktur, zumindest ist er dafür gedacht. Und das, was du machst und ich gemacht habe, ist quasi eine Vergewaltigung

Von Müssen kann natürlich keine Rede sein. Es ist nur eine Möglichkeit und zwar eine, die (höchstwahrscheinlich) "leichteren" Maschinencode erzeugt. Eine class leitet sich ja stets von TObject ab (egal ob da nur klassenstatische Methoden sind oder nicht), also fällt irgendwo Verwaltungsoverhead für die Hierarchien an.

[himitsu]

Record = direkter Speicherblock (da hier keine zusätzliche Speicherverwaltung nötig ist, wurden hier die Opertoren eingebaut)
Objekt = Zeiger auf Speicherblock (implizit mit Referenzen), wobei der Speicherblock quasi auch nur ein Record ist
Interface = Zeiger auf Speicherblock (verstecktes Objekt) mit Referenzzählung (OK, eigentlich ein Eintrittspunkt für mehrere Methoden, zur Interaceverwaltung)
Variant = Record
static Array = mehrere hintereinanderliegende Records (oder Typen) (PS: die RTTI verwaltet das Array genau so)
dynamic Array = Zeiger auf ein static Array, wo vor den Daten noch ein bissl Referenzzählung rumgammelt
String = ein array of Char mit ein paar Extras

Ansonsten können Alle davon Methoden enthalten und bis auf Letztere auch noch Klassenmethoden und Konstruktoren/Destruktoren.

[WladiD]

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