self.free

[RavenIV]

Zitat:

Zitat von faux

ABer wozu denn das alles? Normalerweise zerstört man das Objekt doch mittels dem Deconstructor, oder? Derjenige der ´die Klasse erzeugt, muss sie nach dem Verwenden auch wieder zerstören.

genau, so sehe ich das auch.

was macht self.free() denn für einen Sinn?
woher soll eigentlich das Objekt wissen, dass es nicht mehr benötigt wird?

[sakura]

Zitat:

Zitat von RavenIV

was macht self.free() denn für einen Sinn?
woher soll eigentlich das Objekt wissen, dass es nicht mehr benötigt wird?

Es gibt viele Möglichkeiten dafür. Ein einfaches Beispiel: ein Thread soll im Hintergrund ein Dokument drucken. Wenn der damit fertig ist, dann kann dieser sich ins Nirvana verabschieden - den braucht keiner mehr.

...:cat:...

[SMO]

Ich glaube hier stiftet der Unterschied zwischen Objekten und Referenzen wieder Verwirrung.

Ein Objekt kann viele Referenzen haben. Ein sich selbst zerstörendes Objekt sollte (müsste) alle Referenzen auf sich auf nil setzen. Das geht aber nicht so einfach, denn woher soll es die kennen? Beispiel:

Delphi-Quellcode:

var
  A, B, C: TObject;

A := TObject.Create;
B := A;
C := B;

Damit hätte man ein Objekt aber drei Referenzen darauf. Wenn das Objekt nun zerstört wird, z.B. durch B.Free, dann hat der Destruktor noch nicht mal Kenntnis von B, geschweige denn von A und C. Der "Self" Parameter, der in den Methoden verfügbar ist, ist ein Zeiger auf das Objekt (seine Datenstruktur) und nicht ein Zeiger auf eine der Referenzen.
Genau deshalb gibt es ja z.B. "FreeAndNil". Das ruft Free auf und setzt die übergebene Referenz auf nil. Falls noch andere Referenzen auf das Objekt existieren bleiben sie davon natürlich unberührt.

[user0]

Ebend deshalb will ich wissen, wie man herrausfindet, ob ein Zeiger ins Nichts zeigt. :coder:

[RavenIV]

Zitat:

Zitat von sakura

Zitat:

Zitat von RavenIV

was macht self.free() denn für einen Sinn?
woher soll eigentlich das Objekt wissen, dass es nicht mehr benötigt wird?

Es gibt viele Möglichkeiten dafür. Ein einfaches Beispiel: ein Thread soll im Hintergrund ein Dokument drucken. Wenn der damit fertig ist, dann kann dieser sich ins Nirvana verabschieden - den braucht keiner mehr.

ein Thread ist kein Objekt.
ein Thread wird gestartet und beendet (beendet sich selbst).
ein Objekt wird erzeugt und zerstört.

[dizzy]

Das geht nur über Prüfung auf Zeiger=nil, was aber wiedrum nicht geht, da du bei der angestrebten Variante eben dies nicht machen kannst ;). Ein Zeiger zeigt wenn er nicht nil ist IMMER auf irgendwas. Im schlimmsten Fall halt auf "zufällige" Daten, oder in geschützte Segmente.
Eine Variante die mir einfiele wäre es der Prozedur "Rausschmeissen" die entsprechende Referenz nochmals als var-Parameter mit zu übergeben:

Delphi-Quellcode:

procedure TMyClass.Rausschmeissen(var p: TMyClass);
begin
  p := nil;
  self.Free;
end;

Damit wäre aber nur diese eine übergebene Referenz nil. Jede weitere auf dieses Objekt ist immernoch ungültig nachher.

[tommie-lie]

Zitat:

Zitat von RavenIV

ein Thread ist kein Objekt.

Wenn ich ihn mit BeginThread() starte nicht, richtig, aber eine TThread-Instanz ist ein Objekt (Gips nicht sogar ein Property TThread.FreeOnTerminate?).

Zitat:

Zitat von user0

Es geht um Spielfiguren, die sich gegenseitig rausschmeißen.

So?

Delphi-Quellcode:

TPawn = class
public
  destructor Destroy();

  procedure Capture(var TSpielfigur: aPawn);
  procedure Move(Integer: x, y);
end;


procedure TPawn.Capture(var TPawn: aPawn)
begin
  aSpielfigur.Free;
  aSpielfigur := nil;
  self.Spieler.IncreasePoints(1);
end;

destructr TPawn.Move(x, y)
begin
  if Board[x,y].getPawn() <> nil then // da steht schon jemand
    if Board[x,y].getPawn().getPlayer() <> self.getPlayer then // und der jemand gehört nicht mir
      self.Capture(Board[x,y].getPawn()); // also sacke ich den ein
end;

Keine Ahnung ob die Syntax stimmt, aber laufen müsste es, selbst wenn es sich nicht kompilieren lässt :mrgreen:
Wenn die Spielfigur noch irgendwas hat, was sie freigeben möchte, zum Beispiel irgendwelche Ausrüstung, die die schlagende Spielfigur vorher nicht an sich nimmt, kann sie das im Destruktor tun. Wenn sie sich vorher in irgendeinem Kontrollobjekt "abmelden" muss, kann sie das ebenfalls im Destruktor tun.

[berens]

Tja, genau das Problem habe ich auch gerade:

Stellt euch vor -als Beispiel- ich würde ein Notizzettelprogramm schreiben. Jeder vom Benutzer erstellte Notizzettel (meine Komponente) hat einen "Löschen" Knopf.

Wenn bei der Aktion des Buttons Self.Parent.Free aufgerufen wird, führt das zwangsläufig zu einem Programmabsturz.

Deshalb meine Frage: Wir macht man das sauber? Hab ihr noch nie Komponenten gehabt, die der Benutzer zu Laufzeit erstellen und auch wieder löschen kann?

Wie kann die erstellende Komponente den einzelnen Notizzettel löschen, wenn auf JEDEM Zettel selbst ein Löschen Knopf ist?



Edit: http://www.delphipraxis.net/internal...self+self+free

hat mir den Tag gerettet. Das ist doch alles was ich wollte :)

Evtl "Self" statt "Sender" benutzen.
PostMessage(Self.Handle, WM_KILL_CONTROL, 0, Integer(Self));

[faux]

Aber du greifst ja über die Form auf die Komponente zu und nicht über sich selbst, oder?
Du erstellst die Komponente ja auch nicht über self.Create... :roll:
Über die Klasse, in der du sie erstellst (zB TForm1), in dieser kannst du sie auch wieder Freigeben.

Grüße
Faux

[berens]

*gnaaa* Sorry, aber die Antwort steht schon in allen anderen Threats drinnen, und ich kann die Logik davon ja nachvollziehen, aber wie sieht es mit der praktischen Umsetzung aus? Wenn JEDER Notizzettel (der ja ne eigene Komponente mit nem eigenen "Löschen" Knopf ist) halt einen Löschen Knopf hat, wie setze ich dass logisch um? Wenn "Löschen" auf den aktuellen Zettel angeklick wird, muss ja dann (wenn der Zettel gelöscht wird) auch logischerweise der Löschen Knopf gelöscht werden.
Wie setze ich das um?

Klick --> Benachrichtigung an Form --> löschen durch das Form klappt ja nicht, weil der auslöser der Löschen funktion ja wiederrum mein Löschen Knopf ist.... Zirkelbezug ohne Ende...