Vorteile von Records gegenüber Objekten

[Luckie]

In den neueren Delphi Versionen kann man auch Records mit Methoden und Felder versehen. Was hat das für Vorteile gegenüber Objekten? Warum benutzt man dann nicht gleich Objekte? Wo ist der Unterschied? Ich frage das, weil ich gerade hier im Forum wieder Code gesehen habe, wo Records mit Methoden benutzt werden und ich habe mich gefragt, warum das gemacht wird.

[s.h.a.r.k]

Ich würde behaupten, du meinst meinen Thread :mrgreen:

Warum ich das mache? Der User soll die Möglichkeit haben mit dem Record umgehen zu können, wie mit einem normalen Array. Dafür implementiere ich entsprechende Operator. Zudem sollte er aber auch sowas à la

Delphi-Quellcode:

MyArray.Delete(1, 2);

machen können und das für jeden Array-Typen! Ich erleichtere quasi die Speicherverwaltung und sehr viel Schreibarbeit :stupid:

-- Edit: Schau dir mal TValue an und die Möglichkeiten die du mit diesem Typen hast. Das ist imho ein Paradebeispiel, warum man es so machen kann. Mir ist aber durchaus bewusst, dass hierfür eigentlich Klassen vorgesehen sind, aber da müsste ich mich um die Erstellung und Freigabe der Objekte selbst kümmern, was ich hier umgehen will und auch kann.

[shmia]

1.) Pro Record spart man 4 Bytes (bzw. 8 Byte bei 64Bit-Anwendungen) gegenüber einem Objekt.
Es handelt sich dabei um den verborgenen Zeiger auf die VMT.
2.) man kann Records auf dem Stack (anstelle des Heaps) anlegen und vermeidet dadurch den Aufruf von Create und Free.
Dadurch ist die Gefahr eines versehentlichen Speicherlecks verringert.
3.) Records lassen sich leicht als binäres Abbild in eine Datei speichern oder über ein anderes Medium (Netzwerk) schicken.
Dies gilt aber nur solange keine Zeigertypen wie z.B. String verwendet werden.
Letztendlich landet man aber mit dem direkten Speichern/Laden von Records in der Sackgasse.

[Satty67]

Ich kenne die neuen Record-Fähigkeiten noch nicht, aber denke ein Record ist immer noch einfacher komplett in einer Datei zu speichern, als ein Object.

Ist ein bischen das gleiche Argument, wie von shark (€: und shmia)...

- Speicher-Belegung Record vs. Object.

[Deep-Sea]

Ich liebe erweiterte Records :-D

Nur ein Beispiel, für was ich es nutze:
Bei einem Übertragungsprotokoll habe ich einen Record, der das ein Byte große Kommando repräsentiert. Zusätzlich gibt es ein paar dazu passende Funktionen, die sonst einfach so in der Unit stehen müssten, wie z.B. die Abfrage, ob es sich bei dem Kommando um einen Fehler handelt oder das Umwandeln in einen von Menschen lesbaren Text.
Objekte wären nicht nur ein Overkill für ein Byte Daten, sie würden auch gar nicht so einfach gehen, da ich ja nicht einfach mein komplettes Datenpaket inkl. Kommando in einen Datenstrom wandeln könnte und umgekehrt, da ich ja nur den Zeiger und nicht den Wert auslesen/reinschreiben würde. :stupid:

[WladiD]

Ein weiterer Einsatzzweck ist der erzwungene Namespace in verbindung mit Klassenmethoden. Ist praktisch für Lösungen bei denen es nichts abzuleiten gibt.

Delphi-Quellcode:

unit Probleme;

interface

TMeinProblem = record
  class procedure ErsteLoesung(Eingabe:Integer); static;
  class procedure ZweiteLoesung(Eingabe:Integer); static;  
end;

TEinAnderesProblem = record
  class procedure ErsteLoesung(Eingabe:Integer); static;
  class procedure ZweiteLoesung(Eingabe:Integer); static;
end;

Die Angabe einer Unit zur referenzierung des Namespaces ist ja optional. In diesem Fall zwingt man sich (oder jemand anders) den Namespace anzugeben und die Wahrscheinlichkeit der Verwechslungen von gleichnamigen Methoden sinkt.

[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 :stupid: 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 :mrgreen:

Habe den Thread, in dem das diskutiert wurde, noch rausgesucht: here it is.

[Luckie]

Ok. Dann lasst uns Objekte in die Tonne treten und wir nehmen ab jetzt nur noch Records -- oder wie darf ich das verstehen?

[himitsu]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1099280)

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

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.

[Deep-Sea]

Zitat:

Zitat von Luckie (Beitrag 1099285)

Ok. Dann lasst uns Objekte in die Tonne treten und wir nehmen ab jetzt nur noch Records -- oder wie darf ich das verstehen?

Ich kann deine negative Haltung nicht ganz nachvollziehen :gruebel:
Das ist fast wie die frage, was besser ist: Autos oder Flugzeuge. (Oder Äpfel und Birnen.) Je nach Anwendungszweck bietet sich nun mal entweder das eine oder das andere an.
Es gibt kein besser oder schlechter - nur geeignet und ungeeignet. Alles hat seine Daseinsberechtigung :wink: