Hallo

in den Beispielen bei Embarcadero

http://docwiki.embarcadero.com/RADSt...OS_und_Android)

Wird mal Free und ein anderes mal DisposeOf verwendet.

Kann mit jemand den Unterscheid erklären?

Ciao
Stefan

In Non-ARC Umbegungen ist DisposeOf identisch zu Free .

Bei den ARC-Compilern wird bei DisposeOf zwar der Destructor-Code durchlaufen, aber die Instanz wird noch nicht freigegeben (das erledigt dort ja das ARC). Damit bleiben Referenzen auf die Instanz weiterhin gültig, obwohl das Objekt nicht mehr voll arbeitsfähig ist. Über Disposed kann man diesen Zustand abprüfen.

Als Ergänzung zu Uwe
DisposeOf sollte man meiner Meinung nach nur dann verwenden wenn:

• Innerhalb der Klasse externe Ressourcen, oder grosse Daten (Arrays etc) verwaltet werden und diese zeitnah freigeben werden sollen. zb Streams oder so.
  Man davon ausgeht das mehr wie eine Instancevariable auf diese Instance verweist.
  
  Das verwenden von DisposeOf sollte nur auf die absolut notwendigen Klassen angewendet werden. Ansonsten hat man eigentlich das alte problem mit dem überall prüfen, also so etwas if assigned(var) oder halt bei Arc dann if not var.disposed

Alles in allem eine Design Entscheidung die man sich gut überlegen sollte

Zeitgleich muss man natürlich auch aufpassen das Objekt nach einem DisposeOf nicht mehr anzufassen. "Nicht mehr voll arbeitsfähig" finde ich da sehr harmlos umschrieben. Im Endeffekt ist das nicht mehr viel anders als ein dangling Pointer.

Ein dangling pointer ist etwas gänzlich anderes und hat auch noch seine ganz eigenen Tücken.

NON-ARC (dangling pointer)

Ich habe irgendwo eine Referenz auf eine Instanz vom Typ TFoo. An irgendeiner Stelle im Programm wird diese Instanz freigeben. Jeder Zugriff auf diese Instanz würde jetzt eine Exception produzieren.

Aber, wenn im wieteren Verlauf der Anwendung eine Instanz erzeugt wird, die vom Typ TFoo oder Ableitung ist oder in der VMT an der gleiche Stelle eine Methode mit der gleichen Signatur besitzt und man verwendet jetzt diese alte TFoo Instanz (die, die eigentlich entsorgt wurde), dann gibt es keine Exception (obwohl es eine geben müsste).

Es gibt also ein Szenario, wo es keine Exception gibt, obwohl es eine bräuchte.

ARC

Dieses oben skizzierte Szenario gibt es bei ARC nicht. Nach einem DisposeOf wird zuverlässig eine Exception geworfen, garantiert.

Wieder was gelernt.

Aber ist das mit den exakt passenden Methoden nicht ziemlich unwahrscheinlich? Der mMn interessantere Fall wäre:

Hilft einem ARC weiter wenn man z.B. nur ein Feld einer toten Instanz beschreiben wollte? Wenn ich nicht komplett daneben liege würde unter Nicht-ARC dann halt Speicher beschrieben werden und mit Pech zerstöre ich mir hier etwas anderes.

Wird das unter ARC verhindert wenn der Zeiger dereferenziert wird?

Der einzige Richtige Weg ist zu prüfen ob das Ding noch lebt. Also mit if not class.Disposed
Alles andere ist Murks!!!
Deshalb nur mit klarem Design und klaren Besitzverhältnissen!!
Meiner Meinung nach: Wenn nicht klar ist, wann erzeugt und zerstört wird ist das Design Schrott!

if Assigned(obj) {$IFDEF AUTOREFCOUNT}and not obj.Disposed{$ENDIF} then

Und .Free hat im ARC absolut keinerlei Funktion.
Echt toll, dass man so plattformunabhängigen Code fast nicht mehr schreiben kann, ohne massig IFDEFs.

Zitat:

und klaren Besitzverhältnissen

Klar ist nur, dass du teilweise nicht im Besitz bist.
.Free und früher war das Objekt mal weg ... jetzt ... nja, mal so und mal so.

var [WEAK] variable: type;
In aktuellen Delphis kann das nun endlich auch Windows.
Aber alte Delphis sagen keinen Muggs. Mein Kollege war grade erst drauf reingefallen, dass XE sowas bei IInterface zulässt, aber es still und heimlich ignoriert, da der Compiler keine Warnung wirft, wenn er auf ihm unbekannte Attribute trifft.

Zitat von Der schöne Günther:

Aber ist das mit den exakt passenden Methoden nicht ziemlich unwahrscheinlich?

Ich habe schon mal gesehen, dass der Form-Destructor aufgerufen wurde, weil bei so einer dangling Instanz Free aufgerufen wurde. Blöderweiser lag an der Stelle jetzt diese Form Instanz ... und war weg.

Zitat von Der schöne Günther:

Der mMn interessantere Fall wäre:

Hilft einem ARC weiter wenn man z.B. nur ein Feld einer toten Instanz beschreiben wollte? Wenn ich nicht komplett daneben liege würde unter Nicht-ARC dann halt Speicher beschrieben werden und mit Pech zerstöre ich mir hier etwas anderes.

Wird das unter ARC verhindert wenn der Zeiger dereferenziert wird?

Eine Instanz lebt unter ARC solange, bis jeder diese Instanz-Referenz vergessen hat. Ja, unter ARC wird das verhindert.

Zitat von himitsu:

Echt toll, dass man so plattformunabhängigen Code fast nicht mehr schreiben kann, ohne massig IFDEFs.

Oder man macht sich einen class helper:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TObjectHelper = class helper for TObject
    function IsValid: Boolean;
  end;

function TObjectHelper.IsValid: Boolean;
begin
  Result := Assigned(Self);
{$IFDEF AUTOREFCOUNT}
  if Result then
    Result := not Disposed;
{$ENDIF}
end;

oder eine gleichwertige Hilfsfunktion:

markieren

Delphi-Quellcode:

function InstanceIsValid(Instance: TObject): Boolean;
begin
  Result := Assigned(Instance);
{$IFDEF AUTOREFCOUNT}
  if Result then
    Result := not Instance.Disposed;
{$ENDIF}
end;