Overload und Override für Constructor

[Robert Marquardt]

Manchmal braucht man doch einen andersnamigen Konstruktor.

Delphi-Quellcode:

  TJvHidDeviceReadThread = class(TThread)
  private
    ...
    constructor CtlCreate(const Dev: TJvHidDevice);
  public
    ...
    constructor Create(CreateSuspended: Boolean);
  end;

Create wirft immer eine Exception. Nur CtlCreate funktioniert.
TJvHidDeviceReadThread muss in der interface section stehen, aber trotzdem kann ausserhalb der Unit kein Objekt davon erstellt werden.

[meierotto]

Schön, solch angeregte Diskussion auszulösen
Ich hab mein Problem jedenfalls mit 2 überladenden Konstruktoren gelöst und es funzt.

Danke nochmal

[SirThornberry]

Zitat von BlackJack:

oder wenn man von einer eigenen klasse ableitet, die den constructor virtuell gemacht hat.

edit: könnte man beim 2. Create nicht auch statt override; einfach reintroduce; benutzen?

NEIN! override ist etwas anderes als reintroduce. Mit override wird der originale Constructor überschrieben und mit reintroduce würde man nur die Warnung unterdrücken das der neue Konstructor den alten verdeckt.

[Dax]

Zitat von tommie-lie:

Warum überhaupt override bei Konstruktoren? Die sind doch gar nicht virtuell, macht ja auch keinen Sinn, virtuelle Konstruktoren zu haben

Wieso sollte das keinen Sinn machen?

[tommie-lie]

Zitat von Dax:

Zitat von tommie-lie:

Warum überhaupt override bei Konstruktoren? Die sind doch gar nicht virtuell, macht ja auch keinen Sinn, virtuelle Konstruktoren zu haben

Wieso sollte das keinen Sinn machen?

Virtuelle Methoden nutzen die RTTI um den tatsächlichen Typ ausfindig zu machen und dessen Methode aufzurufen. Ein sehr gutes Beispiel ist der Destruktor einer Klasse, dessen virtualität essenziell ist. Du kannst eine Variable vom Typ TObject haben und dort beliebige andere Typen drin erzeugen (SomeObject := TBlubb.Create). Rufst du jetzt den Destruktor dieser Variable auf, wird tatsächlich nicht der Destruktor von TObject aufgerufen, sondern der der tatsächlichen Instanz (im Beispiel der von TBlubb). Wäre der Destruktor nicht virtuell, würde der Destruktor von TObject aufgerufen, oder man müsste vorher in den richtigen Typ casten (TBlubb(SomeObject).Free), damit auch der richtige Destruktor aufgerufen wird und alle Ressourcen freigegeben werden.
Bei einem Konstruktor ist so ein Verhalten eigentlich unnötig. Ein Konstruktoraufruf sieht in Pascal üblicherweise so aus: SomeVar := TSomeType.Create(Params); Der Datentyp wird also explizit angegeben, es besteht nicht die geringste Frage, welcher Konstruktor aufgerufen werden soll, es muss der von TSomeType sein. Ein Aufruf, bei dem die Laufzeitinformation nötig wäre, wäre SomeVar.Create(Params), der aber keinen Sinn ergibt, da SomeVar entweder noch nicht instanziert war (dann kann es je nach Implementierung des Konstruktor gewaltig knallen, wie wir alle wissen), oder schon ein Objekt besaß, daß aber auch nach dem Aufruf noch in SomeVar bleibt. Es würde alleine der Konstruktor nochmal abgearbeitet werden (mit möglichen Initialisierngsfunktionen. Da ich kein Delphi zur Hand habe, kann ich nicht sagen, ob die üblichen Eigenschaften des Konstruktors auch bei bereits instanzierten Objekten gelten. Falls ja, wird unmittelbar vor dem Aufruf Speicher für eine neue Instanz des Objektes erzeugt und dieser als Rückgabewert zurückgegeben (das ist, was passiert, wenn man SomeVar := TSomeType.Create(Params); aufruft), der aber nirgends wieder referenziert wird. Wieder mangels vorhandenem Delphi bin ich mir nicht sicher, auf welches Objekt self zeigt, wenn man SomeVar.Create aufruft. Zeigt es auf SomeVar (und nicht auf das neu instanzierte Objekt), wäre der u.U. zurückgegebene, nicht referenzierte Speicher auch noch uninitialisiert, selbst wenn ich das Ergebnis also abfangen würde, wäre mein Objekt in einem unerwüsnchten Zustand.
Mir fällt keine Gelegenheit ein, bei der ein virtueller Konstruktor einen praktischen Sinn haben würde, denn von bereits instanzierten Objekten rufe ich keine Konstruktoren auf. Robert meinte, daß ab TComponent der Konstruktor virtual ist, die einzige Erklärung, die ich dafür finde, ist, daß die IDE mit den Komponenten irgendwelche perversen Dinge anstellt, von denen ich lieber nicht wissen möchte, was es ist.

[Chewie]

@tommie-lie: Was ist mit Metaklassen? Da macht folgendes Konstrukt Sinn:

Delphi-Quellcode:

type
  TBlubb = class;
  TSpinatBlubb   = class(TBlubb);

  TBlubbClass = class of TBlubb;

var
  bc: TBlubbClass;
  b: TBlubb;
begin
  bc := TSpinatBlubb;
  b := bc.Create;
end;

Möglicherweise muss in so einem Fall der Konstruktur virtuell sein. Mit Betonung auf möglicherweise, denn ich hab diese Metaklassen nie eingesetzt.

[Flocke]

Zitat von tommie-lie:

Robert meinte, daß ab TComponent der Konstruktor virtual ist, die einzige Erklärung, die ich dafür finde, ist, daß die IDE mit den Komponenten irgendwelche perversen Dinge anstellt, von denen ich lieber nicht wissen möchte, was es ist.

Der Grund dafür wird darin liegen, wie Delphi aus einer DFM-Datei ein Formular initialisiert. Da alle Elemente auf einem Formular von TComponent abstammen, reicht für die Unterscheidung zwischen z.B. TEdit und TListBox einfach die VMT der Klasse; darüber kann man den (virtuellen) Konstruktor finden.

[tommie-lie]

Zitat von Chewie:

Mit Betonung auf möglicherweise, denn ich hab diese Metaklassen nie eingesetzt.

Ich nur selten und eine solche Notwendigkeit ist mir dabei nicht aufgefallen. Ich habe mir die Metaklassen immer als Typ in Variablengewand vorgestellt. Die "Variable" bc in deinem Beispiel wäre demnach selbst nur ein Typ. Diese Vorstellung hat bisher immer gut mit meinen Beobachtungen übereingestimmt, weswegen ich mir nie die Mühe gemacht habe, des genaue Innenleben auseinanderzunehmen.

@Flocke: Genau soetwas meinte ich mit perversen Dingen

[Robert_G]

MetaClasses, und damit virtuelle class methods/properties[1] und Konstruktoren sind doch was feines.
Aber umbenannte Konstruktoren finde ich sogar noch furchtbarer als Benannte im allgemeinen...

[1]OK, in Delphi sind properties nicht virtuell...

[tigerman33]

Wo ist das Problem mit "umbenannten" Konstruktoren? So lange man sich an die Konventionen hält, so dass jeder Konstruktor das Wort "Create" enthält, sollte eigentlich jedem halbwegs durchschnittlich begabten Mitteleuropäer klar sein, dass es sich hierbei um den Konstruktor handelt. Noch dazu, weil man's ja zusätzlich an der Syntax erkennen kann.