Vorteile von Records gegenüber Objekten

[rollstuhlfahrer]

Zitat:

Zitat von himitsu (Beitrag 1099583)

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

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.

Bernhard

[JamesTKirk]

Zitat:

Zitat von himitsu (Beitrag 1099548)

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:

Zitat von NamenLozer (Beitrag 1099559)

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

Delphi-Quellcode:

Integer

dann auch für

Delphi-Quellcode:

LongWord

oder

Delphi-Quellcode:

Byte

funktioniert, oder ein Helper für

Delphi-Quellcode:

Ansistring

auch für

Delphi-Quellcode:

WideString

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

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1099587)

Zitat:

Zitat von himitsu (Beitrag 1099583)

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

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

Delphi-Quellcode:

x := y;

oder

Delphi-Quellcode:

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.

[implementation]

Zitat:

Zitat von himitsu (Beitrag 1099594)

Was passiert bei

Delphi-Quellcode:

x := y;

oder

Delphi-Quellcode:

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.

Ich verstehe nicht, wie du aus einfachen Zuweisungen auf automatische Speicherverwaltung schlussfolgerst. Könntest du das bitte näher erläutern wie du darauf kommst?

[Stevie]

Wenn du bei einem Record mit operator überladung folgendes machst:

Delphi-Quellcode:

a := 1;
b := 2;
a := a + b;

wird bei der Addition a eine neue record Instanz zugewiesen.
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:

a := TMyObject.Create;
b := TMyObject.Create;
a := a + b;

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.

[Luckie]

also jetzt wird es aber kompliziert. :gruebel:

[himitsu]

So kompliziert ist es garnicht.

Delphi-Quellcode:

a := 1;
b := 2;
a := a + b;
b := 3

würde nun wie folgt übersetzt

Delphi-Quellcode:

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

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

Zitat von JamesTKirk (Beitrag 1099639)

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

[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 :oops: ) und nun war Einer schneller :cry:

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

Zitat von Stevie (Beitrag 1099859)

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

[JamesTKirk]

Zitat:

Zitat von Elvis (Beitrag 1099644)

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 :mrgreen:

Gruß,
Sven