Entwickler-Ecke
Delphi Language (Object-Pascal) / CLX - Wird Destructor überschrieben
NewMori - Fr 14.05.10 10:57
Titel: Wird Destructor überschrieben
Hi,
ich habe schon wieder eine Frage. Ich schreibe gerade eine Klasse, von dieser werden mehrere Klassen abgeleitet. Die Pointer der Instanzen werden in einer Liste gespeichert. Wenn ich jetzt die Pointer habe und mit
Delphi-Quelltext
1:
| TPlayer(Pointer).Destroy |
aufrufe, wird dann der Destructor der eigendlichen Klasse zB. TLocalPlayer aufgerufen, also als hätte ich Destroy als abstract deklariert oder wir das Destroy von TPlayer aufgerufen. Mir geht es hier darum ob ich immer die richtige Klasse kennen muss oder ob es reicht das Destroy der Elternklasse aufzurufen.
bummi - Fr 14.05.10 11:10
Hängt davon ba wie Du en Destroctor implementierst:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46:
| unit Unit1;
interface
uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;
type TMk=Class(Tobject) Destructor Destroy; override; End; TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private public end;
var Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject); var p:TObject; begin p := TMK.Create; p.Destroy; end;
destructor TMk.Destroy; begin Showmessage('Kaputt'); inherited; end;
end. |
NewMori - Fr 14.05.10 11:17
Das ist, was ich nicht haben will, es sollen alle Destructoren der reinfolge nach abgearbeitet werden. Kann man Delphi nicht klarmachen, das der alte verschoben werden soll ud durch den neuen ersetzt wird.
Bzw: Override funktioniert doch nur wenn die Funktion vorher Virtuell war, oder nicht?
bummi - Fr 14.05.10 11:25
ich fürchte ich verstehe Dein Problem nicht ....
destroy ist virtual
und IMHO verhält sich alles so wie es soll
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57:
| unit Unit1;
interface
uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;
type
TMkPrior=Class (Tobject) Destructor Destroy; override; End; TMk=Class(TMkPrior) Destructor Destroy; override; End; TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private public end;
var Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject); var p:TObject; begin p := TMK.Create; p.Destroy; end;
destructor TMk.Destroy; begin Showmessage('Kaputt'); inherited; end;
destructor TMkPrior.Destroy; begin Showmessage('Prior Kaputt'); inherited; end;
end. |
NewMori - Fr 14.05.10 11:28
Sorry,
ich habe bis jetzt mit virtual; abstract; gearbeitet und nicht gewusst, das man virtual auch alleine einsetzen kann. :oops:
Danke bummi für die Antworten
Narses - Fr 14.05.10 11:32
Moin!
Zur Sicherheit: Laut DOH sollte man nicht den Destruktor direkt, sondern statt dessen .Free aufrufen. :idea:
cu
Narses
NewMori - Fr 14.05.10 11:41
Bei Free wird doch nur noch mal auf Nil geprüft, oder? Ich höre die ganze Zeit was anderes die einen sagen Free die anderen Destroy was ist denn der Unterschied?
bummi - Fr 14.05.10 11:44
Free könnte auch schon überschrieben sein ...
BenBE - Fr 14.05.10 11:49
Der Unterschied ist, dass die Compiler-Magic beim Aufruf von Destroy eine andere ist, weil Destroy als Destructor einen versteckten Parameter mitbekommt, der das Speichermanagement betrifft. Von daher IMMER Obj.Free; Obj:=Nil; aufrufen oder FreeAndNil(Obj);.
NewMori - Fr 14.05.10 12:03
Das heißt, dass ich dann auch Free überschreiben sollte oder nicht?
Narses - Fr 14.05.10 12:17
Moin!
NewMori hat folgendes geschrieben : |
Das heißt, dass ich dann auch Free überschreiben sollte oder nicht? |
Nein, warum? Du überschreibst den Destruktor, aber rufst .Free auf, fertig. ;)
cu
Narses
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!