Vorteile von Records gegenüber Objekten

[JamesTKirk]

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:

var
  a: TObject;
begin
  a := TObject.Create;
  (...)
  a := TObject.Create;
  (...)
  a.Free;
end.

Gruß,
Sven

[Elvis]

Zitat von JamesTKirk:

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.

Es ging Himitsu wohl nicht darum ob es möglich ist.
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:

a + b         -> leak
Ergebnis + c -> leak
x + y         -> leak
Ergebnis / z -> leak

Das ist doch totaler Mist. Es sind genau diese nicht-offensichtlichen Fallstricke, die C++ so unbeliebt machen.
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...

[JamesTKirk]

Zitat von Elvis:

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

Der Punkt ist, dass FPC das bereits unterstützt - als globale Operatoren und das auch schon länger als Delphi. Es wäre also nur die logische Fortführung eines bereits existierenden Features.

Aber genug dazu. Erstmal müssen die Generics richtig funktionieren, da hab ich noch genug zu tun

Gruß,
Sven

[himitsu]

Du kannst da eben nicht manuell aufräumen, denn wenn man da mal weitergeht

Delphi-Quellcode:

a := (b + c) * d + e;

aka

t1 := b + c;
t2 := t1 * d;
a := t2 + e;

oder einfach nur

Delphi-Quellcode:

a := a + b;

aka

t := a + b;
a := t;

Wo will man denn hier die temporären Zwischenergebnisse freigeben?


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 ) und nun war Einer schneller

[Stevie]

Wenn jemand auf Biegen und Brechen operatoren und Objekte verknuspern will, soll er sich TCustomVariantType anschauen.

[Luckie]

Ok, ich denke, ich werde Records weiterhin als Datencontainer nutzen und nur wenn ich Daten haben, wo es sinnvoll ist (zum Beispiel beim konvertieren in andere Datentypen) Records benutzen. Ansonsten werde ich wohl wie früher Objekte Benutzen.

[himitsu]

Zitat von Stevie:

Wenn jemand auf Biegen und Brechen operatoren und Objekte verknuspern will, soll er sich TCustomVariantType anschauen.

Wobei dieses eigentlich wieder über ein Interface und den Typ Variant geht, welcher wiederrum ein Record ist.