Vorteile von Records gegenüber Objekten

[Luckie]

Zitat von Elvis:

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 von Luckie:

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

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

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

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

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 von himitsu:

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

Genau sowas meinte ich.