Vorteile von Records gegenüber Objekten

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

Bernhard

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

[implementation]

Zitat von himitsu:

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.

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.

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

[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