Wann .Free und wann .Destoy benutzen

[sirius]

Zitat:

Zitat von mkinzler

Zitat:

Wäre doch mal ein Ding, wenn die Free-Methode demnächst autmatisch den Zeiger auf nil setzt

Wird wohl nicht gehen. dafür gibt es ja aber FreeAndNil()

Wir wollen hier objektorientiert programmieren und müssen dann auf so eine stupide Prozedur zurückgreifen.
Der Compiler muss halt einfach einmal mehr mitdenken und beim Aufruf von free die self-varaible als Referenz übergeben.

[xaromz]

Hallo,

Zitat:

Zitat von sirius

Wäre doch mal ein Ding, wenn die Free-Methode demnächst autmatisch den Zeiger auf nil setzt :mrgreen:

viel zu kurz gedacht:

Delphi-Quellcode:

var
  A, B: TObject;
begin
  A := TObject.Create;
  B := A;
  A.Free;
end;

Angenommen, Free setzt A auf nil, welchen Wert hat dann B?

Gruß
xaromz

[mkinzler]

Er müsste erkennen, daß eine Variable außerhalb des Scopes der Klasse die gerade freigegebene Instanz referenziert und diese dann auf Nil setzen.

[xaromz]

Hallo,

Zitat:

Zitat von mkinzler

Er müsste erkennen, daß eine Variable außerhalb des Scopes der Klasse die gerade freigegebene Instanz referenziert und diese dann auf Nil setzen.

Überprüfung aller Variablen auf mögliche Verweise? Jetzt weiß ich, wozu wir Quad-Prozessoren brauchen :mrgreen: .

Gruß
xaromz

[mkinzler]

Zitat:

Überprüfung aller Variablen auf mögliche Verweise?

Nein er könnte ja schon den Zusammenhang von der Methode und dem Objekt auf dem es angewandt wurde. Meine Frage war als Antwort auf Sirius' Antwort gedacht und sollte zeigen, daß es nicht so einfach ist.

[sirius]

@xaromz: Das ist ja ne alberne Annahme. Was kann denn der Compiler dafür wenn ich mir irgendwo den Pointer auf ein Objekt noch ein zweites oder drittes Mal merke. auch freeandnil setzt bei dir B nicht auf nil. So kann ich (wenn auch etwas umständlicher wegen den Referenzzählern) auch strings etc."austrixen".
Dafür gibts eben Referenzzähler, und zack sind wir bei Interfaces angelangt.

@mkinzler

Delphi-Quellcode:

procedure Tobject.free(var self:Tobject);
begin
  if self<>nil then destroy
  self:=nil;
end;

Das ist Aufgabe des Compilers, da mal eine Referenz zu geben.

[mkinzler]

Nur das das setzen von self auf nil unnötig ist, da nach dem Ende der Methode self nicht mehr existiert. Aber die variable, die das Objekt referenziert hat immer noch den Wert.

[Hawkeye219]

Hallo,

Zitat:

Zitat von SirThornberry

Mit Compilermagic geht einiges.

Zitat:

Zitat von sirius

Der Compiler muss halt einfach einmal mehr mitdenken und beim Aufruf von free die self-varaible als Referenz übergeben.

wie würdet ihr das - als Compilerbauer - im folgenden Fall lösen?

Delphi-Quellcode:

TDemoClass = class
private
  ...
public
  property Control: TWhateverClass
    read GetControl write SetControl;
end;

var
  Instance : TDemoClass;
begin
  ...
  Instance.Control.Free;
  ...
end;

Das Beispiel wirkt konstruiert, aber ähnliche Codestücke findet man in der VCL.

Ein automatisch generiertes "Instance.Control := nil" nach dem Aufruf der Free-Methode funktioniert nur, wenn der Setter dies geeignet verarbeitet. Welchen Code soll der Compiler erzeugen, wenn kein Setter vorhanden ist?

Die Prozedur FreeAndNil ist ein einfaches Werkzeug, mit dessen Hilfe der Programmierer eine Instanz freigeben und eine zugehörige Referenz sicher löschen kann. Nur der Programmierer kann wissen, wann und wo das geschehen sollte, und ob eventuell weitere Referenzen existieren, die ebenfalls gelöscht werden müssen.

Gruß Hawkeye

[xaromz]

Hallo,

Zitat:

Zitat von sirius

@xaromz: Das ist ja ne alberne Annahme. Was kann denn der Compiler dafür wenn ich mir irgendwo den Pointer auf ein Objekt noch ein zweites oder drittes Mal merke. auch freeandnil setzt bei dir B nicht auf nil.

die Annahme ist nicht albern. Es geht hier um die Konsistenz. Mit FreeAndNil setze ich explizit eine Variable. Free tut das nicht. Wäre dem so, hätten wir ein ziemlich komisches Konstrukt: Eine Methode wirkt sich auf die Variable aus, über die sie aufgerufen wurde, aber auf keine andere. In einer solchen Sprache möchte ich nicht programmieren.

Gruß
xaromz

[sirius]

Zitat:

Zitat von xaromz

Hallo,
die Annahme ist nicht albern. Es geht hier um die Konsistenz. Mit FreeAndNil setze ich explizit eine Variable. Free tut das nicht. Wäre dem so, hätten wir ein ziemlich komisches Konstrukt: Eine Methode wirkt sich auf die Variable aus, über die sie aufgerufen wurde, aber auf keine andere. In einer solchen Sprache möchte ich nicht programmieren.
Gruß
xaromz

Programmierst du aber :mrgreen:

Delphi-Quellcode:

var s:string;
begin
  //jetzt ist s nil
  s:='Hallo Welt';
  //und jetzt zeigt s ganz woanders hin
  //ähnliches für dynamische Arrays
end;

@Hawkeye
Na du übergibst bei free "einfach" noch den zweiten Parameter mit, der auf nil gesetzt werden soll. Bei create wird ja auch noch vom Compiler die TypeInfo mitgeliefert. Es gibt noch weitere Funktionen (freemem/dispose), wo der Compiler einfach noch 1 Parameter mit anhängt. Und wenn du mit mehreren Referenzen auf ein Objekt arbeitest, dann nimm doch lieber ein Interface.

Generell besteht bei sowas natürlich immer die Frage der Sinnfälligkeit. Aber wann brauch man denn nochmal einen Zeiger auf ein Objekt, dass nicht mehr existiert? Und wieviele Probleme diesbezüglich tauchten schon in der DP auf ("assigned funktoiniert nicht!" --> "Du musst den Zeiger auf nil setzen")?