[XE2] Live Bindings

[Thom]

Zitat von Stevie:

Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache.

Dumme Frage: Weshalb? Und was verstehst Du unter "vermischen"?

[Stevie]

Zitat von Thom:

Zitat von Stevie:

Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache.

Dumme Frage: Weshalb? Und was verstehst Du unter "vermischen"?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o);
  // Objekt wurde freigegeben, da RefCount auf Null gesunken ist
end;

[Thom]

Vielleicht sollte man den Aufruf korrekt durchführen?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o as IInterface); //<- RefCount wird automatisch erhöht
  //Objekt "lebt" noch!
end;

[mquadrat]

Das mag zwar das korrekte Ergebnis liefern, ist aber extremst unintuitiv.

[Thom]

Eine korrekte Programmierung ist "extremst unintuitiv" und eine falsche Handhabung führt zur Schlußfolgerung "Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache."



Ich habe den Eindruck, daß einige Leute gar nicht mehr ohne "Compiler-Magie" leben können und wenn diese mal versagt, kommt gleich das große Gezetere und der Hinweis darauf, wie toll das andere Sprachen hinbekommen...

[Stevie]

Zitat von Thom:

Vielleicht sollte man den Aufruf korrekt durchführen?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o as IInterface); //<- RefCount wird automatisch erhöht
  //Objekt "lebt" noch!
end;

Gratulation, du hast den Scope nun auf die komplette Routine erweitert. Führt trotzdem dazu, dass o am Ende freigegeben wird. Mit diesem Vorgehen kann man gut RAII in Delphi umsetzen.

Zitat von Thom:

Ich habe den Eindruck, daß einige Leute gar nicht mehr ohne "Compiler-Magie" leben können und wenn diese mal versagt, kommt gleich das große Gezetere und der Hinweis darauf, wie toll das andere Sprachen hinbekommen...

Ich hab den Eindruck, dass du nicht weißt, wovon du sprichst. Klar, in dem Beispiel, hast du dem Objekt ein paar Zeilen mehr Lifetime geschenkt. Löst aber nicht das Problem, dass die Referenzzählung irgendwann unweigerlich zuschlägt. Das kann man nur durch explizites Aufrufen von _AddRef umgehen. Und dann hast du das Problem bloß verschoben, denn in dem Fall musst du entweder die Objekt Referenz so lange rumschleppen, bis du es freigeben musst, oder über einen cast des interfaces das dahinterliegende Objekt freigeben, da dass ja durch das Aushebeln der Referenzzählung durch das explizite um 1 erhöhen nicht mehr automatisch freigegeben wird. Fakt ist, ohne die Referenzzählung auszuschalten, bekommst du keine gescheite Vermischung von TInterfacedObject Derivat Referenzen und interface Referenzen hin.

[Thom]

Stevie,

ich fasse das einmal zusammen:

• Ich stelle eine Frage, um eine - meiner Meinung nach - fragwürdige Aussage Deinerseits besser zu verstehen.
• Daraufhin bringst Du ein Beispiel, das auf einer unkorrekten Handhabung basiert.
• Ich weise nach, daß das von Dir angesprochene Problem zu umgehen ist.

Anstatt jetzt zu sagen bzw. zu schreiben: "Ja, das könnte man so machen, aber..." kommt

Zitat von Stevie:

Gratulation, du hast den Scope nun auf die komplette Routine erweitert. Führt trotzdem dazu, dass o am Ende freigegeben wird.
[...]
Ich hab den Eindruck, dass du nicht weißt, wovon du sprichst.

"o am Ende freigegeben wird"? Aha... Wo in Deinem Beispiel wird die Verwendung des Objektes o nach Beendigung der Prozedur außerhalb beschrieben? Daß Interfaces bzw. Objekte mit einem Interface automatisch freigegeben werden, wenn die Referenzzählung bei Null angekommen ist, ist ja gerade eine grundlegende Idee dieser Technik. Will man solche Objekte erhalten, muß man lediglich den Referenzzähler explizit erhöhen, falls das eben nicht durch "Compiler-Magie" erledigt wird.

Zitat:

Fakt ist, ohne die Referenzzählung auszuschalten, bekommst du keine gescheite Vermischung von TInterfacedObject Derivat Referenzen und interface Referenzen hin.

Ich schon - wenn Du's nicht hinbekommst, solltes Du Dich fragen, weshalb...

Vielen Dank für diese eindrucksvolle Demonstration Deiner Fachkenntnisse und deiner Überheblichkeit.

[Stevie]

Der erste, der in diesem Thread "überheblich" daher kam (was ich im übrigens nicht so aufgefasst habe, ich bin da relativ unempfindlich), warst du mit folgender Aussage:

Zitat von Thom:

Ich habe den Eindruck, daß einige Leute gar nicht mehr ohne "Compiler-Magie" leben können und wenn diese mal versagt, kommt gleich das große Gezetere und der Hinweis darauf, wie toll das andere Sprachen hinbekommen...

Nebenbei versagt in meinem Beispiel überhaupt keine "Compiler-Magie". Dein Softcast führt nur zu einem weiteren AddRef und Release (schau in den Debugger, wenn du mir nicht glaubst), welche den Lifecycle des Objekts auf den gesamten Prozedurbereich ausdehnen, anstatt nur auf den Call der Test Prozedur. Ähnliches passiert, wenn man eine Funktion hat, die eine Referenz zurückliefert, man diese aber nicht irgendwo speichert.

Außerdem war mein Beispiel das Minimalste, um zu zeigen, was passiert, wenn man Objektreferenz und Interface Referenz vermischt - und ich bin davon ausgegangen, dass man das auf ein komplexeres Szenario (Objekt wird außerhalb dieser Routine weiterverwendet) abstrahieren kann.

Eventuell überzeugt dich jemand, der mehr Ahnung von Delphi hat (Zweiter Absatz: "That basically means that mixing object references and interface references is dodgy". Und auch andere Delphi Entwickler sind schon in diese Falle getappt und es wird auch regelmäßig auf die Gefahren beim Vermischen (siehe die beiden letzten Absätze in der accepted answer) von beidem hingewiesen.

Falls das Erklären dieses fundierten Sachverhalts als Überheblichkeit missinterpretiert werden konnte, entschuldige ich mich dafür.

[Union]

Ich hab da mal eine mehr praxisorientierte Frage: Wie führe ich eigene Methoden und Konverter sinnvoll ein und wie konfiguriere ich diese, dass sie in der Topologie Vorrang haben?

Beispielsweise habe ich ein Edit an eine Property eines anderen Controls gebunden. Wird er Inhalt des Edits gelöscht und ein Notify ausgeführt, so knallt es natürlich mit einem EConversionError, weil ja folgendes passiert:
StrToInt('') Ich könnte das natürlich ganz oben beim Notifier individuell abfangen, nur brauche ich dann keine LiveBindings mehr

[QuickAndDirty]

Zitat von Thom:

Vielleicht sollte man den Aufruf korrekt durchführen?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o as IInterface); //<- RefCount wird automatisch erhöht
  //Objekt "lebt" noch!
end;

Sowas sollte meiner Ansicht nach über die Syntaxprüfung geregelt sein...zu mindest mit einer Warnung a la "prüfen sie ob das Object Referenzzählung implemtiert"