AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Warum virtual / override bei destructor / constructor?
Thema durchsuchen
Ansicht
Themen-Optionen

Warum virtual / override bei destructor / constructor?

Ein Thema von HJay · begonnen am 22. Mai 2017 · letzter Beitrag vom 14. Jan 2023
Antwort Antwort
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.313 Beiträge
 
Delphi 12 Athens
 
#1

AW: Warum virtual / override bei destructor / constructor?

  Alt 22. Mai 2017, 18:12
Außerdem gibt es nicht nur einen Constructor und die rufen sich auch noch oft gegenseitig auf ... weißt du was das für ein Chaos wird, wenn die alle Virtuell wären, dann weiß man schnell garnicht mehr was in welcher Reihenfolge aufgerufen wird.

Der Destructor heißt in der Regel immer gleich und hat keine Parameter, also geht es da immer schön gradlinig nach oben durch.
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu (22. Mai 2017 um 18:15 Uhr)
  Mit Zitat antworten Zitat
HJay

Registriert seit: 7. Dez 2009
172 Beiträge
 
Delphi XE7 Enterprise
 
#2

AW: Warum virtual / override bei destructor / constructor?

  Alt 22. Mai 2017, 18:57
OK, vielen Dank an alle für Eure Erklärungen!
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.490 Beiträge
 
Delphi 11 Alexandria
 
#3

AW: Warum virtual / override bei destructor / constructor?

  Alt 23. Mai 2017, 12:33
Bei uns in der Firma ist es Pflicht constructoren virtuell zu machen mit Verweis auf http://www.delphipraxis.net/668250-post12.html
(reintroduce ist schon noch erlaubt.)
  Mit Zitat antworten Zitat
Alallart

Registriert seit: 8. Dez 2015
155 Beiträge
 
#4

AW: Warum virtual / override bei destructor / constructor?

  Alt 14. Jan 2023, 13:51
Bin heute zufällig auf diesen Thread gestoßen und weil die Frage interessant klang, durchgelesen. Auch wenn der Thread inzwischen alt ist, glaube ich, dass die Frage noch einige interessiert. Vielleicht liest es jemand noch. Vielleicht kann ich eine einfache Antwort geben. Falls ich richtigliege, wäre es nett wenn es einer bestätigen könnte, ansonsten wiedersprechen. Ich denke Anwort #4 sagt bereits wieso es so ist, aber etwas allgemein.

Warum also sind Destruktoren virtual und Konstruktoren nicht? Die kurze Antwort: Konstruktoren müssen es nicht, Destruktoren sollten es, sonst könnte es sein, dass die nicht korrekt ausgeführt werden.

Tabelle siehe Anhang!

Um das zu verstehen habe ich eine kleine Tabelle erstellt. Sie beschreibt vier Klassen. TKlasseC ist von TKlasseB abgeleitet, TKlasseB von TKlasseA, TKlasseA von TObject. Alle Klassen haben einen Konstruktor Create und einen Destruktor Destroy.

Den Konstruktor Create ignorieren wir vorerst, und konzentrieren und auf Destroy. Wie gesagt, alle Klassen haben ein Create und ein Destroy, aber nur TObject hat Free. Man könnte auch ein eigenes Free in jede Klasse einbauen (also A, B und C), aber wer macht das schon? Es gibt ja das Free von TObject, und das reicht. Es macht ja seinen Job. Also wozu ein eigenes Free programmieren?

Und hier liegt meiner Meinung nach des Pudels Kern. Destroy ist wegen Free virtual (u.a.).

Nehmen wir mal an ich erstelle die drei Klassen und gebe sie zum Schluss mit Free frei. Jede Klasse (also A, B und C) hat in Create und Destroy einen Code der beim freigeben ausgeführt werden muss. Das Destroy von TObject ist leer, aber alle anderen haben etwas Wichtiges drinstehen. Wenn ich also KlasseC freigebe, müssten die Destroys alle vier Klassen ausgeführt werden. Weil sie voneinander abstammen. Werden sie das?

Nehmen wir mal an keiner der Destroys (also von A, B, C und TObject) ist virtual. Was wird alles ausgeführt? Meiner Meinung nach nur das Destroy von TObject. Sonst keines.

Warum? Weil in dem Fall das Destroy von TObject statisch ist, also auch eine feste Adresse auf seinen Code bekommt. Warum sollen in dem Fall die anderen Destroys ausgeführt werden? Rufe ich aus TKlasseC Free auf, ruft das das Destroy von TObject auf. Einzig und alleine. Wegen der statischen Adresse. Das Free hat TKlasseC von TObject geerbt, d. h. dieses Free greift eigentlich nur auf das Destroy von TObject zu.

Nehmen wir jetzt an das Destroy von TObject ist virtual und von den anderen override. Ruft KlasseC Free auf, ruft das, wie gehabt, das Destroy von TObject auf, weil Free eine Methode von TObject ist. Das hat aber keine statische Adresse auf seinen Code, weil virtual. Also geht es weiter zu Destroy von TKlasseA. Auch das ist nicht statisch, also geht es weiter an das Destroy von KlasseB, und zuletzt an das von KlasseC. Erst das hat eine Adresse auf seinen Code. In dem Fall den Code von Destroy von TKlasseC. Das Programm sagt "To". Nun geht es wieder abwärts, wegen inherited. Nun wird Destroy von TKlasseB aufgerufen, das Programm sagt "Tac", dann von TKlasseA ("Tic") und zuletzt von TObject.

Deses Problem hat Create nicht, weil Create direkt aus der jeweiligen Klasse aufgerufen wird. Inherited erledigt dann den Rest, d. h es werden auch die Create von den abgeleiteten Klassen ausgeführt. Destroy wird nicht direkt aufgerufen, sondern über Free. Und das ist nur in TObject vorhanden. Würde man Destroy direkt aufrufen, müsste es nicht virtual sein.

Würde man ein Free in TKlasseC programmieren, würde es direkt auf das Destroy von TKlasseC zugreifen. In dem Fall könnte man drauf verzichten Destroy virtual zu machen.

Das ist meine Erklärung dazu. Falls ich richtigliege, kann es einer bitte bestätigen? Würde mich interessieren.
Angehängte Grafiken
Dateityp: png Img.png (21,6 KB, 31x aufgerufen)

Geändert von Alallart (14. Jan 2023 um 13:55 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.313 Beiträge
 
Delphi 12 Athens
 
#5

AW: Warum virtual / override bei destructor / constructor?

  Alt 14. Jan 2023, 14:54
Create Contructor kann man so viele haben, wie man will ... sie müssen auch nicht Create heißen.
Ob man die virtual macht oder nicht hängt vom Anwendungsfall ab.
z.B. bei TComponent, da ruft der DFM-Loader ausschließlich das TComponent.Create auf, daher muß man das auch überschreiben.
Egal ob ein Create am Ende anders heißt ... grundsätzlich sollte man immer sicherstellen, dass das originale "Create" (bzw. das Create des Vorfahren) am Ende dennoch immer ausgeführt wird (inherited).

Free wird niemals überschrieben, es lässt sich auch garnicht überschreiben.
Destroy wird stattdessen überschrieben und man darf niemals das Override vergessen.

Genauso ruft man Destroy eigentlich auch nie direkt auf.
Free ruft auch auch immer nur TObject.Destroy auf, weswegen man dieses überschreiben muß, damit sichdergestellt wird, dass immer alles ordnungsgemmäß freigegeben wird.
Ja, man könnte technisch andere Destructor erstellen, aber da ist nie sichergestellt, dass sie auch aufgerufen werden.
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu (14. Jan 2023 um 15:00 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:47 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz