Vorteile von Records gegenüber Objekten

[himitsu]

Zitat von Progman:

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


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 Array of TObjekt macht da dann schon mehr arbeit, als ein Array of Record .
Einfach ein einziges SetLength und schon sind alle Records vorhanden.

[hanspeter]

Zitat von himitsu:

Ein Array of TObjekt macht da dann schon mehr arbeit, als ein 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.

[JamesTKirk]

Vorteil class :
* Vererbung (inklusive virtuelle Methoden)
* implizite Pointer auf den Heap

Vorteil 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 object (wer sagt, dass die deprecated sind, mag für Delphi recht haben, aber nicht für FPC (erst recht nicht im Compiler selbst )):
* konstante Initialisierung möglich
* liegen auf dem Stack
* Vererbung (inklusive virtuelle Methoden)

Gruß,
Sven

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

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