Zitat von
Muetze1:
Zitat von
Khabarakh:
Zitat von
Muetze1:
Es muss vor allem nur ein virtueller Constructor Create definiert werden in der TImport_Virtual - kein abstrakter!
Die Ableitungen müssen ihn überschreiben und dann wird dieser auch aufgerufen...
Warum _muss_ der Konstruktor virtuell sein? Wenn die Basisklasse rein abstrakt ist und nicht irgendwelche Felder befüllen muss, kann der Konstruktor doch auch abstrakt sein.
Könnte er, aber das wäre so wie eine vorhandene, implementierte Methode in einer Ableitung der Klasse als abstrakt zu deklarieren und somit die vorhandene Implementation wegzuschmeissen. Abstrakt soll die Ableitungen zwingen bestimmte Methoden zu implementieren und da es immer einen Konstruktor von TObject gibt und du ihn in einer Ableitung abstrakt machst, wie willst du diesen dann noch gross aufrufen, so dass dieser Speicherplatz reservieren kann und Daten initialisieren kann?
Wirf mal einen Blick in den
VCL-Quellcode
. Der Konstruktor von TObject als Methode an sich hat überhaupt nichts mit Alloziierung zu tun (besser gesagt: er ist einfach leer), man kann ihn getrost weglassen. Ihn trotzdem aufzurufen kann zwar nicht schaden und kann man auch zu gutem Code-Style zählen, aber ein abstrakter Konstruktor ist eben problemlos möglich und auch sinnvoll. Wenn der Programmierer versucht, aus Versehen die abstrakte Basisklasse zu instanziieren, wird er gleich mit einer
Exception getadelt
(wenigstens ein kleiner Nachbau der sinnvollen abstrakten Klassen von .NET). Bei einer anderen Basisklasse gibt es dann immer noch virtual (wobei eine Abstrahierung einer spezialisierten Klasse meist wenig sinnvoll ist).
Zitat:
Grundlegend ist es unlogisch und eigentlich sollte Delphi auch einen Fehler bringen bei dem gleichen Weg mit einer Methode anstatt eines Constructors. Aber durch die besondere Stellung des Konstruktors wird er es wohl akzeptieren, aber ich wage zu bezweifeln, dass er es mit einer Methode so mit sich machen lässt (Behauptung/Vermutung meinerseits ohne es jetzt nachzuprüfen).
Meinst du damit, eine Methode mit eine abstrakten zu überdecken? Wie ich oben schon geschrieben hab, warum sollte das nicht möglich sein? Eine abstrakte Methode ist erst einmal einfach eine Methode, und diese verdeckt eben gleichnamige geerbte Member. Das mag nicht immer sinnvoll, bei einer
leeren überdeckten Methode aber sich nicht verwerflich sondern wie oben gezeigt sogar nützlich sein.
Zitat:
Zitat von
Khabarakh:
Zitat von
tomsel:
Genau! Die Variable "Import" ist ja wohl vom Typ TImport_Virtual. Da TImport_Virtual den Construktor von TObject nicht überschreiben kann, ihn aber auch nicht verdeckt, wird halt TObject.Create aufgerufen.
Aha, und TObject.Create wirft dann eine EAbstractError-
Exception 
. Natürlich wird der Konstruktor von TObject wie jede andere Methode von einem gleichnamigen Konstruktor (egal ob abstrakt oder nicht) verdeckt.
verdeckt, aber nicht überschrieben.
Ja. Das habe ich so geschrieben und auch so gemeint
.
Zitat:
Da die Metaklasse so definiert wurde:
TImportClassType = class of TImport_Virtual;
Wird in deinem Falle immer TImport_Virtual.Create aufgerufen, aber nie der Konstruktor der Ableitung, da dieser nur durch ein überschreiben (sprich dynamischer/virtueller Konstruktor) aufgerufen wird.
Beziehst du dich auf den ersten Post? Denn mittlerweile
hat glkgereon ja seinen Konstruktor abstrakt deklariert und überschrieben (auch wenn er irgendwo noch einen Fehler haben muss
).