Vorteile von Records gegenüber Objekten

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

[JamesTKirk]

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

Wer sagt das dies notwendig ist? Ich kann in FPC zum Beispiel bereits mit globalen Operatoren mein Beispiel von oben umsetzen. Das liest sich dann so:

Delphi-Quellcode:

type
  TIntClass = class
    Value: Integer;
    constructor Create(aValue: Integer);
  end;

operator + (aLeft, aRight: TIntClass): TIntClass;
begin
  Result := TIntClass.Create(aLeft.Value + aRight.Value);
end;

Zitat von NamenLozer:

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?

Mir kam beim implementieren von class und record helpern durchaus der Gedanke, dass man sowas auch machen könnte (konsequenterweise dann natürlich auch "interface helper" und "object helper").

Beispiel:

Delphi-Quellcode:

TIntegerHelper = type helper for Integer
  (...)
end;

Wobei natürlich dann die Frage aufkommt, ob ein "type helper" für Integer dann auch für LongWord oder Byte funktioniert, oder ein Helper für Ansistring auch für WideString . Dieses Problem besteht bei Records weniger, da diese nicht einfach durch Zuweisungen ohne Casts "ineinander umgewandelt" werden können.

Zitat von rollstuhlfahrer:

Zitat von himitsu:

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.

Konnte Delphi .NET das nicht schon von Haus aus? - Ich hab gerade das komische Gefühl im Bauch, dass da zwischendurch ein Rückschritt passiert ist. Oder Emba hat nicht die .NET-Zusatzfeatures in die Win32-Version übernommen

Ich behaupte mal letzeres. Generics haben ja auch ne Weile gebraucht, bis sie implementiert waren.

Gruß,
Sven

[himitsu]

Zitat:

Dieses Problem besteht bei Records weniger, da diese nicht einfach durch Zuweisungen ohne Casts "ineinander umgewandelt" werden können.

Dafür richtet man einen impliziten Cast für die anderen Typen ein und schon kann man sowas auch für Records hinbekommen.

Zitat:

Wer sagt das dies notwendig ist? Ich kann in FPC zum Beispiel bereits

Was passiert bei x := y; oder y := 123; oder wenn eine Variable freigegeben wird?

Würde man sowas in Delphi implementieren wollen, dann müßte man Objekte automatisch freigeben, was dann den bekannten Prinzipien der Objekte wiedersprechen würde.

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