AW: Vorteile von Records gegenüber Objekten
Zitat:
Bernhard |
AW: Vorteile von Records gegenüber Objekten
Zitat:
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:
Beispiel:
Delphi-Quellcode:
Wobei natürlich dann die Frage aufkommt, ob ein "type helper" für
TIntegerHelper = type helper for Integer
(...) end;
Delphi-Quellcode:
dann auch für
Integer
Delphi-Quellcode:
oder
LongWord
Delphi-Quellcode:
funktioniert, oder ein Helper für
Byte
Delphi-Quellcode:
auch für
Ansistring
Delphi-Quellcode:
. Dieses Problem besteht bei Records weniger, da diese nicht einfach durch Zuweisungen ohne Casts "ineinander umgewandelt" werden können.
WideString
Zitat:
Gruß, Sven |
AW: Vorteile von Records gegenüber Objekten
Zitat:
Zitat:
Delphi-Quellcode:
oder
x := y;
Delphi-Quellcode:
oder wenn eine Variable freigegeben wird?
y := 123;
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. |
AW: Vorteile von Records gegenüber Objekten
Zitat:
|
AW: Vorteile von Records gegenüber Objekten
Wenn du bei einem Record mit operator überladung folgendes machst:
Delphi-Quellcode:
wird bei der Addition a eine neue record Instanz zugewiesen.
a := 1;
b := 2; a := a + b; Bei operator Überladungen wird bei binären Operationen für Result eine neue record Instanz erzeugt. Was würde also passieren, wenn das diesem Fall Objekte wären? Wie wollte man den Speicher verwalten, wenn munter für Result neue Instanzen erzeugt würden und die Referenzen von Objekten in Variablen, denen dieses Ergebnis zugewiesen wird verloren gehen?
Delphi-Quellcode:
Was würde hier passieren? Es müsste eine neue Instanz als Ergebnis für die Addition erstellt werden und die Referenz auf die vorher in Zeile 2 erstellte Instanz ginge bei der Zuweisung in Zeile 3 verloren.
a := TMyObject.Create;
b := TMyObject.Create; a := a + b; |
AW: Vorteile von Records gegenüber Objekten
also jetzt wird es aber kompliziert. :gruebel:
|
AW: Vorteile von Records gegenüber Objekten
So kompliziert ist es garnicht.
Delphi-Quellcode:
würde nun wie folgt übersetzt
a := 1;
b := 2; a := a + b; b := 3
Delphi-Quellcode:
Es werden fleißig neue Objekte erzeugt, welches mit Delphi-Objekten ja noch geht, aber wer würde sich nun um die vielen Objekte kümmern?
a := TMyRecord.Create(1);
b := TMyRecord.Create(2); a := TMyRecord.Add(a, b); // a := TMyRecord.Create(a.Value + b.Value); b := TMyRecord.Create(3); Es wäre ja nun fatal, wenn Delphi in diesem Fall die Referenz einfach so freigeben würde, denn ohne Referenzzählung weiß ja nur der Programmierer (sollte er zumindestens), ob noch andere Referenzen auf dieses Objekt existieren. |
AW: Vorteile von Records gegenüber Objekten
Man muss eben mehr aufpassen, wenn man es mit Klassen und überladenen Operatoren zu tun hat. Delphi/Pascal ist eben nicht .NET, wo einem der übriggebliebene Müll weggeräumt wird.
Sowas sollte man ja schließlich auch nicht machen (solange man nicht noch eine Referenz übrig hat):
Delphi-Quellcode:
Gruß,
var
a: TObject; begin a := TObject.Create; (...) a := TObject.Create; (...) a.Free; end. Sven |
AW: Vorteile von Records gegenüber Objekten
Zitat:
Vieles ist möglich. Allerdings ist es etwas was man nicht in der Sprache haben will. Man muss sich immer ganz genau überlegen, was die der Enduser rein intuitiv alleine durch das Vorhandensein von Feature X für Vorstellungen macht. Und Operatoren für Klassen sind halt alles andere als trivial nachzuvollziehen. Denn du hast dann sowas hier stehen, und musst dran denken auch ja jedes einzelne Zwischenergebnis freizugeben: miep := (a + b + c) = (x + y) / z;
Code:
Das ist doch totaler Mist. Es sind genau diese nicht-offensichtlichen Fallstricke, die C++ so unbeliebt machen.
a + b -> leak
Ergebnis + c -> leak x + y -> leak Ergebnis / z -> leak Das ist etwas, was Opensource-Sprachen wie Ruby oder Groovy erst noch lernen müssen: Manchmal ist weniger mehr. Und nicht alles was man machen kann, ist den Aufwand der daraus folgenden Komplexizität wert. Sowas hinzuzufügen würde bedeuten, dass man ab dem Moment jedes Stück Code, was Operatoren nutzt, darauf prüfen muss, ob man Leaks erzeugt. Damit wirst du dir im FPC-Team sicherlich KEINE Freunde machen. Vor allem, weil viele da sogar noch verbohrter und "traditioneller" sind als es der durchschnittliche Delphi-User ist... |
AW: Vorteile von Records gegenüber Objekten
Du kannst da eben nicht manuell aufräumen, denn wenn man da mal weitergeht
Delphi-Quellcode:
oder einfach nur
a := (b + c) * d + e;
aka t1 := b + c; t2 := t1 * d; a := t2 + e;
Delphi-Quellcode:
Wo will man denn hier die temporären Zwischenergebnisse freigeben?
a := a + b;
aka t := a + b; a := t; Mit Interfaces wäre es also noch möglich (siehe http://www.delphipraxis.net/topic151373.html , auch wenn es dort "nur" eine Umleitung ist, da es ja direkt nicht geht), aber Operatoren und Objekte vertragen sich einfach nicht. Und autormatisch von Delphi freigeben kann man es auch nicht lassen, da Objekte eben keine Referenzzählung besitzen. Das endet dann so, als wenn man zwei TObjektList's oder TStringList's nimmt, überall das das Objekt-Owner auf True setzt, beiden Listen das selbe Objekt gibt und sich dann wundert, warum es knallt. [edit] Mist, vergessen zu Senden (sendeknopf nicht richtig getroffen :oops: ) und nun war Einer schneller :cry: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz