Interface "überladen" vorhandener Methoden?

[Der schöne Günther]

Ich komme nicht hinterher. Ich dachte, im "NextGen"-Compiler ("IFDEF AUTOREFCOUNT") rufen nun sowohl Objekt- und Interface-Referenzen beide _AddRef und _Release auf. Sohingegen muss man sich

• Objekt-referenzierte Instanzen nicht mehr explizit freigeben
• Kann die gleiche Instanz lustig objekt- und interface-referenzieren ohne sich Sorgen zu machen

Wo läge denn der Sinn, zwei unterschiedliche Referenzzähler zu haben?

[himitsu]

Wenn die Beide das Selbe aufrufen, dann würde es gehn, also wenn es da nur eine Zählvariable gäbe.
Das hieße dann, daß die einfach aus jedem Objekt ein Interface machen?

Könnte natürlich auch sein, daß ARC selber zählt, also und unabhängig von den Interfaces.

[Sir Rufo]

Zitat von Der schöne Günther:

Ich komme nicht hinterher. Ich dachte, im "NextGen"-Compiler ("IFDEF AUTOREFCOUNT") rufen nun sowohl Objekt- und Interface-Referenzen beide _AddRef und _Release auf. Sohingegen muss man sich

• Objekt-referenzierte Instanzen nicht mehr explizit freigeben
• Kann die gleiche Instanz lustig objekt- und interface-referenzieren ohne sich Sorgen zu machen

Wo läge denn der Sinn, zwei unterschiedliche Referenzzähler zu haben?

Eben es gibt nur einen Referenzzähler, aber es funktioniert andersherum (wie ein Blick in die Quellen zeigt)

Delphi-Quellcode:

function TInterfacedObject._AddRef: Integer;
begin
{$IFNDEF AUTOREFCOUNT}
  Result := AtomicIncrement(FRefCount);
{$ELSE}
  Result := __ObjAddRef;
{$ENDIF}
end;

[himitsu]

Zitat:

__ObjAddRef

Jetzt weiß ich wieder, warum ich erstmal davon ausging, daß sie selber zählen ... schonmal das "Wort" gelesen, ala hier irgendwer etwas über ARC schrieb.

Ein Blick in die Quellen war mir irgendwie zu teuer.
Ohhh, XE3 kennt das auch schon.

Ein bissl unpraktisch ist jetzt nur, daß die Vererbung immernoch nicht generisch funktioniert type TXyz<T> = class(T) , sonst hätte Emba diese Funktion leichter veröffentlichen können.
Denn ich hab ein paar Interfaces, die erst später, in der Vererbung, zu einem gemacht wurden, also nicht schon von Anfang an von TInterfacedObject abgeleitet sind.
Dort hatte ich mir den Code einfach nur kopiert, welcher ja nun falsch ist.

[Stevie]

Meine Aussage bezog sich auf die ausgeschaltete Referenzzählung für Interfaces in einer Klasse (z.B. TComponent). Bei einer solchen bringt auch ARC nix, da die Interface Referenz (welcher aber ja wie gesagt, nix zum RefCount beiträgt) langlebiger sein kann, als die Objektinstanz (welche ja durch ARC bei Verlassen des Scopes für das Freigeben sorgt)

[himitsu]

Stimmt, da hast du recht.

Wenn bei aktivem ARC die Interfacereferenzen ans ARC weitergeleitet werden,
dann müsste man ja bei allen Interfaces, welche "anders" zählen, ja das ARC deaktiviert werden.
So gesehn, wurde das dann doch falschrum implementiert, weil das ARC hätte besser seine Referenzen ans Interface weitergeben müssen?



Toll, noch mehr zum Grübeln.
Mein Model für einen kreuz- und querverlinkten Interfacebaum, aus mehreren Interfaces, die sich gegenseitig referenzieren sollen, wird immer verwirrender.
Ich wollte eigentlich eine Vorlage schaffe, wo soein Verhalten "sicher" ablaufen kann.
- jeder kennt/referenziert sich gegenseitig (Parent und Childs)
- Childs werden freigegeben, wenn sie weder extern, noch von einem/mehreren Parents referenziert werden
- Parents bleiben aber so lange vorhanden, wie extern auf sie referenziert wird, oder von/auf deren Parents, bzw. auf deren Childs
- wird der oberste Parent freigegeben, und es existieren weder auf ihn, auf dessen Childs und deren Childs eine Referenz, erst dann verschwindet alles
- ...

Zum Glück hab ich die neuen Schnittstellen für's himXML so geschaffen, daß es dort "extern" und intern auch nur kurz beim Erstellen niemals Objektreferenzen gibt,
sonst hätte mir das blöde ARC jetzt schon einen strich durch die Rechnung gemacht. Ich hoffe zumindestens, daß es das nicht macht (prüfen kann ich's ja nicht mehr)

[Stevie]

Zitat von himitsu:

Wenn bei aktivem ARC die Interfacereferenzen ans ARC weitergeleitet werden,
dann müsste man ja bei allen Interfaces, welche "anders" zählen, ja das ARC deaktiviert werden.
So gesehn, wurde das dann doch falschrum implementiert, weil das ARC hätte besser seine Referenzen ans Interface weitergeben müssen?

Wie soll ARC an Interfaces irgendwas weitergeben. Die Referenzzählung bei Interfaces ist ein Implementierungsdetail der implementierenden Klasse.
Wenn man es genau betrachtet und berücksichtigt, dass man seinen Code nicht von Implementierungsdetails abhängig machen soll, bewegt man sich bei der Referenzzählung und Programmierung gegen Interfaces genau genommen schon ziemlich in einer Grauzone.

Gegen ein grausames Design, in dem man Objekt und Interface Referenzen bunt vermischt und keinen Plan mehr über die genauen Lebenszyklen und Scopes der Dinger hat, ist noch kein Kraut gewachsen. Man könnte jetzt wieder für einen GC argumentieren, aber auch den kann man verwirren, so dass ohne ihm auf seltsamste Weisen unter die Arme zu greifen, Speicherlecks entstehen.

[Der schöne Günther]

Oder anders herum. Es ist noch nicht allzu lange her, da hat der Java-GC immer gerne die Singletons gefressen