Nja, im Prizip greifen dann in etwa die selben Mechianismen bei Objekten, wie sie schon für Interfaces gelten.
Mal im Ernst, wir haben doch Interfaces
und Objekte.
Wenn man das Verhalten eines Interfaces will, dann sollte man Dieses doch auch verwenden?
(bekommt man den schweren Anhänger nicht weg, dann spannt man einen 
Traktor davor und nicht den Ferrari)
Ich freu mich schon auf die Verknubbelung der verschiedenen Techniken.
TComponent+Owner, Interfaces mit und ohne Referenzzählung, das Free/Destroy der Objekte und dann noch das Neue.
Außerdem, wenn schon Garbage Collector, dann doch gleich richtig?
Hier ist es scheinbar ausschließlich für Objekt-Instanzen vorgesehn.
Also die neue Funktion ... Interfaces, dynamische Arrays, LongStrings und Variant mal außer Acht gelassen, woran sich seit Jahrzehnten, praktisch schon fast immer, nichts dran geändert hat.
Ach ja, es geht übrigens um den Compilerschalter
{$IFDEF AUTOREFCOUNT}
[WARUMHABENWIRKEINENSPOILERODERSO]
Der sich eventuell duch einen Parserfehler(?) schon massenhaft in der OH eingenistet hat.
Zitat von
Wie ich dieses Parsermistding hasse -.-:
Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen. Bitte unterstützen Sie uns bei der Dokumentation dieses Themas, indem Sie Ihre Kommentare auf der Diskussionsseite eingeben.
[/WARUMHABENWIRKEINENSPOILERODERSO]
und vermutlich das Attribut
[Weak]
synopse - Delphi XE3 is preparing reference counting for class instances
Roman's Blog
Einfache Beispiele, welche bestimmt an vielen Stellen Probleme bereiten
könnten werden, wären z.B. die TList und alles Andere, wo "Objekte" in einem Data-"Pointer" hinterlegt werden.
Oder Objekte per Messages verschicken. (programmintern natürlich)
In Delphi werden bis jetzt problemlos Objekte ständig umhergecastet (OK, bei Win64 nicht ganz unproblematisch, aber da sind die Programmierer ja praktisch obftmals selber dran Schuld)
und genau an diesen Stellen muß es doch zangsläufig die Referenzzählung falsch zählen.
Kreuzreferenzen werden eventuell auch Spaß bereiten.
- ObjektB kennt ObjektA (in einem Feld gespeichert)
- ObjektA kennt und verwaltet ObjektB (in einem Feld gespeichert)
- im Destructor von A wird B freigegeben
Da hier aber eine Referenz von A in B drinsteckt, wird nichmal mehr beim A.Free der Destructor aufgerufen, da es ja noch eine weitere Referenz gibt.
Wie/Ob die es machen, daß beim Freigeben von A die Referenz in B automatisch auf nil gesetzt wird, würde ich gerne wissen (klingt aber so, als wenn die das eventuel machen wollen?)
Ganz im Ernst. Wie haben doch schon Interfaces ... warum verwendet man Diese nicht einfach, wenn man ihre Funktionalität z.B. für WinRT benötigt.
Ich hatte doch auch mal vorgeschlagen, daß man die Interfaceverwaltnug/-erstellung für sowas hätte vereinfachen können.
Im Compiler eine Funktion/Befehl, welcher aus den Public-Schnittstellen eines Objektes "automatisch" ein Interface erstellt.
z.B.:
Delphi-Quellcode:
type
TMyObject =
class(TInterfacedObject)
public
function Irgendwas: Integer;
end as IMyInterface['
{6C68C66B-ED43-42D1-8BF2-B41327A31673}'];
// mit oder ohne GUID
IMyInterface sähe in diesem Fall dann intern so aus:
Delphi-Quellcode:
type
IMyInterface = interface
['{6C68C66B-ED43-42D1-8BF2-B41327A31673}']
function Irgendwas: Integer;
end;
Wenn die keine Lust haben für ihre neue WinRT-
API für jedes Objekt ein Interface zu erstellen, dann ginge das auch automatisch, ohne die Objekte selber
verschandeln umbauen zu müssen.