Interface "überladen" vorhandener Methoden?

[Mavarik]

OK Danke... Dann ist meine Idee erst mal vom Tisch.

Mavarik

[himitsu]

Das Problem ist jetzt nur, wie sich nun auch noch dieses komische ARC dort einmischt, bzw. wie Dieses die eh schon teilweise nicht ganz so einfache Verknüpfung von Objekt und interface beinflusst.

[Stevie]

Zitat von himitsu:

Das Problem ist jetzt nur, wie sich nun auch noch dieses komische ARC dort einmischt, bzw. wie Dieses die eh schon teilweise nicht ganz so einfache Verknüpfung von Objekt und interface beinflusst.

Genauso, als ob du auf eine Objektreferenz, welche du an ein Interface zugewiesen hast, Free aufrufst. Wenn die Interface Referenz einen größeren Scope bzw längere Lebensdauer hat, dann raucht sie dir ab, um dich mal zu zitieren.

[himitsu]

Nja, wenn die Objktreferenzen und die Interfacerferenzen beide mitzählen ... wer hat dann die Kontrolle über die Freigabe des Objekts?
Wenn da keiner aufpasst, müsste doch zwangsläufig der freigeben, welcher zuerst bei 0 ankommt.

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