Problem mit ARC unter iOS?

[bra]

Wie Darlo schon geschrieben hat, lässt sich das am einfachsten mit Instruments verfolgen, da kann man sich u.a. die komplette Struktur der noch vorhandenen Objekte anzeigen lassen.

Ein Objekt auf nil zu setzen reicht bei ARC nicht unbedingt. Solange noch irgendwelche Verweise auf das Objekt vorhanden sind, wird es nicht freigegeben. Ich habe mir dazu auch zu Debugging-Zwecken eine eigene Routine erstellt:

Code:

procedure TryFree(const AUnitName: String; const AObj: TObject);
begin
  if not Assigned(AObj) then
    Exit;
{$IFDEF AUTOREFCOUNT}
  if AObj.RefCount > 1 then begin
    OutputDebugStrFmt('[[%s]] %s.RefCount=%d', [AUnitName, AObj.QualifiedClassName, AObj.RefCount]);
    AObj.DisposeOf;
  end;
{$ELSE}
  AObj.Free;
{$ENDIF AUTOREFCOUNT}
end;

Die ist ziemlich nützlich, auch um Leaks in den Delphi-Komponenten zu finden.

[romber]

Zitat von bra:

Ein Objekt auf nil zu setzen reicht bei ARC nicht unbedingt. Solange noch irgendwelche Verweise auf das Objekt vorhanden sind, wird es nicht freigegeben.

Das stimmt. Aber die Controls werden in meinem Fall in der Methode lokal deklariert und nur in dieser Methode benutzt. Neben Controls selber setze ich auch noch für jedes Control den Parent auf nil.

Zitat von bra:

...Ich habe mir dazu auch zu Debugging-Zwecken eine eigene Routine erstellt

Vielen Dank dafür! Werde ich gleich ausprobieren!

[Sir Rufo]

Man braucht keine Unterscheidung zu machen.

TObject.DisposeOf testet selber auf nil und ruft den Destructor auf (egal ob ARC oder nicht).

TObject.Free testet selber auf nil und ruft den Destructor auf (nur bei NICHT-ARC)

Will man also eine Komponente ins Jenseits befördern, nimmt man generell DisposeOf .
Genauso mit Streams und sonstigen Instanzen, die noch Ressourcen halten, die man jetzt gesichert freigeben möchte.

Für den Rest nimmt man Free oder FreeAndNil .

[romber]

Zitat von Sir Rufo:

Will man also eine Komponente ins Jenseits befördern, nimmt man generell DisposeOf .

Werden dabei auch all die Komponenten freigegeben, die in jenseits zu befördernde Komponente als Owner referenzieren?
Was passiert, wenn auf dem mit DisposeOf gekillten Control andere Controls liegen, die es als Parent referenzieren?

[Sir Rufo]

Wird eine TComponent Instanz zerstört werden auch alle Components zerstört.
Wird eine TWinControl Instanz zerstört werden auch alle Children zerstört.
Wird eine TFmxObject Instanz zerstört werden auch alle Children zerstört.

TObject.DisposeOf zerstört ohne Wenn und Aber (ARC oder nicht).

Einfache und alte Regel ... nur das mit dem DisposeOf ist neu.

[romber]

Zitat von Sir Rufo:

Wird eine TComponent Instanz zerstört werden auch alle Components zerstört.
Wird eine TWinControl Instanz zerstört werden auch alle Children zerstört.
Wird eine TFmxObject Instanz zerstört werden auch alle Children zerstört.

TObject.DisposeOf zerstört ohne Wenn und Aber (ARC oder nicht).

Einfache und alte Regel ... nur das mit dem DisposeOf ist neu.

Bei mir führt DisposeOf zum Absturz der App. Und zwar prüfe ich zuerst, ob DetailsView bereits existiert und kille diese ggfs. mit DisposeOf. Danach erstelle ich die DetailsView wieder. Sobald ich Controls auf das neu erzeugte DetailsView setze, stürzt die App ab.

[himitsu]

Und was sagt der Debugger?
Also WO stürzt es denn ab?

Bei TComponents gibt es auch noch Verbindungen zwischen den Controls, welche Referenzen darstellen und somit die Komponenten am Leben erhalten.
Und wenn du dir wirklich nicht sicher bist, ob etwas freigegeben wird, dann bau z.B. eine MessageBox/Logging in den Destructor und fertig.

Und warum verdammt nochmal ist man auf diese bescheuerte Idee mit dem DisposeOf gekommen und hat nicht einfach auch im ARC mit Free das "wirklich" freigeben können?
Also das aus DisposeOf ins Free eingebaut.

[romber]

Zitat von bra:

Code:

procedure TryFree(const AUnitName: String; const AObj: TObject);
begin
  if not Assigned(AObj) then
    Exit;
{$IFDEF AUTOREFCOUNT}
  if AObj.RefCount > 1 then begin
    OutputDebugStrFmt('[[%s]] %s.RefCount=%d', [AUnitName, AObj.QualifiedClassName, AObj.RefCount]);
    AObj.DisposeOf;
  end;
{$ELSE}
  AObj.Free;
{$ENDIF AUTOREFCOUNT}
end;

Wo kommt denn die OutputDebugStrFmt her? Kann nichts dazu finden.

[bra]

[QUOTE=romber;1327772]

Zitat von bra:

Wo kommt denn die OutputDebugStrFmt her? Kann nichts dazu finden.

Das ist eine eigene Routine von uns, die einfach nur eine Meldung ins iOS-Log ausgibt.