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:

[WladiD]

Zitat:

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

@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:

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.

[s.h.a.r.k]

Zitat:

Zitat von Deep-Sea (Beitrag 1099290)

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:

Du hast die unglaubliche Philosophie von Programmierern vergessen :mrgreen: Ist halt immer so, die einen mögen es und die anderen würden die einen dafür, dass sie das verwendet haben, am liebsten verbrennen :stupid:

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

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

Delphi-Quellcode:

array of Char

mit ein paar Extras

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

[Deep-Sea]

Zitat:

Zitat von Luckie (Beitrag 1099294)

Aber bisher wurden nur Vorteile von Records genannt.

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

[WladiD]

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

[himitsu]

Zitat:

Zitat von Deep-Sea (Beitrag 1099297)

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:

Zitat von WladiD (Beitrag 1099299)

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:

Zitat von Luckie (Beitrag 1099294)

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? :gruebel: (rot = meine Verbesserung)

Zitat:

Zitat von himitsu (Beitrag 1099287)

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

[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 :P

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

Zitat von Progman (Beitrag 1099310)

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?! :wink:


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

[s.h.a.r.k]

Zitat:

Zitat von hanspeter (Beitrag 1099311)

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:

Zitat von Progman (Beitrag 1099310)

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 :angle:


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:

Array of TObjekt

macht da dann schon mehr arbeit, als ein

Delphi-Quellcode:

Array of Record

.
Einfach ein einziges SetLength und schon sind alle Records vorhanden.

[hanspeter]

Zitat:

Zitat von himitsu (Beitrag 1099315)

Ein

Delphi-Quellcode:

Array of TObjekt

macht da dann schon mehr arbeit, als ein

Delphi-Quellcode:

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. :angle:

[JamesTKirk]

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:

object

(wer sagt, dass die deprecated sind, mag für Delphi recht haben, aber nicht für FPC (erst recht nicht im Compiler selbst :P )):
* konstante Initialisierung möglich
* liegen auf dem Stack
* Vererbung (inklusive virtuelle Methoden)

Gruß,
Sven

[himitsu]

Zitat:

Zitat von JamesTKirk (Beitrag 1099366)

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

Das wird und kann sich auch nicht ändern.

Zitat:

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

[Luckie]

Zitat:

Zitat von Elvis (Beitrag 1099382)

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.

Das hat aber nichts mit meiner Frage zu tun. Record als Datentyp usw. ist klar, aber warum ein Record mit Methoden, welches sich dann verhält wie ein Objekt. Das war mein Problem.

[Elvis]

Zitat:

Zitat von Luckie (Beitrag 1099396)

Das hat aber nichts mit meiner Frage zu tun. Record als Datentyp usw. ist klar, aber warum ein Record mit Methoden, welches sich dann verhält wie ein Objekt. Das war mein Problem.

Naja, wenn du einen eigenen Datentyp baust, sind Methoden á la ToString oder statische á la TryParse doch sehr intuitiv und praktisch.

[himitsu]

Da gibt es z.B. sowas
http://www.delphipraxis.net/122045-b...tml#post848903
welches man sich so kapseln könnte.

Delphi-Quellcode:

Type 
  ThMD5 = Record
    Data: MD5_CTX;
    Procedure Init;
    Procedure Update(Input: Pointer; inLen: LongWord);
    Function  Final: MD5_RES;
  End;

Dieser Record ist nun vollkommen kompatibel zur WinAPI
oder man nutzt die eingebetetten Record-Methoden.

Und am Ende kann man es auch noch ausmotzen, bis zum Geht nicht mehr und es bleibt immernoch kompatibel zur WinAPI.
Außerdem läßt sich soein Record direkt und ohne umwege irgendwo abspeichern/übertragen (Stream, Datei, Indy usw.)

Delphi-Quellcode:

Type 
  ThMD5 = packed Record
    Data: MD5_CTX;

    Class Operator Implicit(Value: MD5_CTX): ThMD5;            Inline;
    Class Operator Implicit(Rec: ThMD5): MD5_CTX;              Inline;
    Class Operator Implicit(Rec: ThMD5): MD5_DIGEST;           Inline;
    Class Operator Equal   (Left, Right: MD5_CTX):    Boolean; Inline;
    Class Operator Equal   (Left, Right: MD5_DIGEST): Boolean; Inline;
    Class Operator NotEqual(Left, Right: MD5_CTX):    Boolean; Inline;
    Class Operator NotEqual(Left, Right: MD5_DIGEST): Boolean; Inline;

    Procedure Init;                                              Inline;
    Procedure Update(Input: Pointer; inLen: LongWord); Overload; Inline;
    Procedure Update(Const Input: AnsiString);         Overload; Inline;
    Procedure Update(Const Input: WideString);         Overload; Inline;
    Procedure Update(Input: TStream; inLen: LongInt);  Overload;
    Function  Final: MD5_RES;                                    Inline;

    Function Calc(Input: Pointer; inLen: LongWord):     ThMD5; Overload; Inline;
    Function Calc(Const Input: AnsiString):             ThMD5; Overload; Inline;
    Function Calc(Const Input: WideString):             ThMD5; Overload; Inline;
    Function Calc(Var Input: TnStream; inLen: LongInt): ThMD5; Overload; Inline;
    Function CalcFile(Const FileName: WideString; Var Hash: MD5_DIGEST): Boolean;

    Function asBin:       MD5_DIGEST; Inline;
    Function asHexString: String;

    Function asGUID:      TGUID;
  End;

[arnold mueller]

Ich denke Records und Objekte haben jeder für sich ihre Daseinsberechtigungen.

Objekte nehme ich immer dann wenn ich auf Konstruktor/Destruktor angewiesen bin. Records verwende ich - wie bisher auch - um Daten zusammen zu fassen.

Die "neuen" Records finde ich gut, käme aber nicht auch die Idee auf biegen und brechen unbedingt einen Record anstelle eines Objekts zu nehmen.
Eine meiner Favoriten ist eine Clear-Methode in Records, das steigert meiner Meinung nach die Code-Qualität.

Code:

TMyRecord: record
  A: integer;
  B: integer;
  procedure clear;
end;

TMyRecord.Clear;
begin
  FillChar(self,SizeOf(self),0);
end;


TForm1.Button1Click(Sender: TObject)
var
  r1: TMyRecord;
begin
  r1.Clear;
end;

Bei der Verarbeitung von Datenströmen - seriell oder TCP ist mal egal - haben die "neuen" Records echt Vorteile. CRC-Berechnung, Telegramm-Validierung, Parsing kann alles im Record laufen. Das macht den Code viel übersichtlicher.

-
arno

[JamesTKirk]

Zitat:

Zitat von himitsu (Beitrag 1099369)

Zitat:

Zitat von JamesTKirk (Beitrag 1099366)

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

Das wird und kann sich auch nicht ändern.

Zitat:

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.

Was bitte ist das für eine fadenscheinige Begründung? Und was hat die Verwendung von Operatoren mit Garbage-Collection zu tun? Das man in einer nativen Programmiersprache bezüglich dem Freigeben von Objekten mehr aufpassen muss als in .NET oder Java muss den Anwendern eben bewusst gemacht werden.

Delphi-Quellcode:

type
  TIntClass = class
    Value: Integer;
    class operator Add(aLeft, aRight: TIntClass): TIntClass;
    constructor Create(aValue: Integer);
  end;

constructor TIntClass.Create(aValue: Integer);
begin
  Value := aValue;
end;

var
  a, b, c: TIntClass;
begin
  // try ... finally wird absichtlich weggelassen
  a := TIntClass.Create(31);
  b := TIntClass.Create(11);
  c := a + b;
  Writeln('c: ', c.Value);
  a.Free;
  b.Free;
  c.Free;
end.

Ich sehe jetzt zum Beispiel auch nichts was mich daran hindern würde dies in FPC zu implementieren (Operatoren für Interfaces wären allerdings wieder interessanter zu implementieren). Wenn mir mal langweilig ist, muss ich mal einen Proof of Concept machen :mrgreen:

Gruß,
Sven

[himitsu]

Zitat:

Und was hat die Verwendung von Operatoren mit Garbage-Collection zu tun?

Garnichts ... jedenfalls nicht direkt.

Aber für Operatoren wird eine automatische Speicherverwaltung benötigt und diese ist bei Objekten nicht vorhanden.
Nja, bei Systemen mit einem Garbage-Collector, wird oftmals nahezu alles automatisch verwaltet (es sei denn man schaltet dieses geziehlt ab).

[FredlFesl]

Records als alternative zu DTO (Data Transfer Objects) sind schon legitim, also als reine Datencontainer. Dafür kann man natürlich eine Klasse nehmen, aber hier haben Records einfach weniger Overhead.

Aber erweiterte Records finde ich persönlich bescheuert. Dafür (also für die Funktionalität) sind Klassen da. Wenn ich mein DTO zunächst als Record modelliere, und später merke, das ich die eine oder andere Methode doch benötige, soll ich gefälligst umsteigen oder eine Klasse schreiben, die die benötigten Methoden definiert.

Aber ich kann natürlich auch einfach das Record erweitern. Das ist dann im wahrsten Sinne des Wortes "RAPID Prototyping", also schnell schnell angepasst. Leider wird der Code damit unsauber und daher lehne ich das ab.

[Namenloser]

Wieso kann man eigentlich nicht primitive Typen um Methoden erweitern? So könnte man z.B. Integer.ToString schreiben wie man das aus anderen objektorientierten Sprachen kennt. (Früher fand ich das ja hässlich, weil es quasi voraussetzt, dass alle Typen sich gegenseitig kennen, aber andererseits ist es doch irgendwie ganz praktisch...)

Oder geht sowas inzwischen?

[himitsu]

Erweitern geht sowieso nicht, da Records und normale Typen keine Vererbung kennen :zwinker:

Aber "Record Helper" für normale Typen wäre schon was schönes :cry:

Einen Record, darin einen Integer, noch die ganzen Operatoren und vorallen die implizizen und expliziten Typumwandlungen und schon hast du einen erweiterten Integer.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1099583)

Aber "Record Helper" für normale Typen wäre schon was schönes :cry:.

Genau sowas meinte ich.