Verwirrung mit override/overload bei Constructoren

[hsg]

Es ist zwar kein richtiges Problem (es läuft zwar) aber trotzdem ich bin bei folgendem Konstrukt nicht mehr wirklich sicher, was da passiert:

Delphi-Quellcode:

interface
type
TTextEditor= class(TMyForm)
  public
   constructor Create(AOwner : TComponent); overload; override;  // <----- ES GEHT UM DIESE ZEILE
   constructor Create(AOwner : TComponent; lNEm : Boolean); reintroduce; overload;
end;

implementation
//----------------------------------------------------------------------------------------------------------------------
// Klasse erzeugen - Default konstruktor
//----------------------------------------------------------------------------------------------------------------------
constructor TTextEditor.Create(AOwner : TComponent);
begin
  inherited Create(AOwner);
  lNotEmpty := False;
end;

//----------------------------------------------------------------------------------------------------------------------
// Klasse erzeugen - Konstruktor mit Parameter
//----------------------------------------------------------------------------------------------------------------------
constructor TTextEditor.Create(AOwner : TComponent; lNEm : Boolean);
begin
  inherited Create(AOwner);   // <-- Welcher Konstruktor wird hier warum aufgerufen
  lNotEmpty   := lNEm;
  ActionCancel.Enabled  := not lNotEmpty; 
end;

In der obigen Form kompiliert Delphi ohne zu meckern.

Bei folgenden Varianten kommen entweder Warnungen (nicht schön, will ich weg haben) oder gar Fehler:

Variante 1:

Delphi-Quellcode:

   constructor Create(AOwner : TComponent); override; overload;  // <----- ES GEHT UM DIESE ZEILE
   constructor Create(AOwner : TComponent; lNEm : Boolean); reintroduce; overload;

Fehler: Feldbezeichner nicht erlaubt nach Methoden oder Eigenschaften

Variante 2:

Delphi-Quellcode:

   constructor Create(AOwner : TComponent); overload;  // <----- ES GEHT UM DIESE ZEILE
   constructor Create(AOwner : TComponent; lNEm : Boolean); reintroduce; overload;

Warnung: W1010 Methode 'Create' verbirgt virtuelle Methode vom Basistyp 'TFormPPS'

Wer klärt mich auf????

[SirThornberry]

variante1 geht nicht weil du overload und override in der falschen Reihenfolge hast.
Und bei variante2 sagt doch die Fehlermeldung aus was nicht stimmt - deine Create-methode verbirgt eben die die Create-Methode von der klasse wovon du ableitest.

[Robert Marquardt]

Brauchst du wirklich zwei Konstuktoren? Geht es nicht vielleicht nur mit dem zweiten und einem Parameter mit Defaultwert?

Es ist ganz klar was bei "inherited Create(AOwner)" aufgerufen wird. Es wird der Konstruktor von TMyForm aufgerufen. Falls Du dort nicht ebenfalls an den Konstruktoren spielst, hat diese Klasse nur einen Konstruktor. Selbst wenn es mehrere Konstruktoren gibt, sichert Delphi ab das es immer eindeutig bleibt. es gibt Fehlermeldungen falls die Deklaration der overloaded Konstruktoren/Methoden nicht eindeutig ist.

[SirThornberry]

überschreiben des alten constructors muss sein damit die ide weiterhin den TComponent-Nachfahren erzeugen kann.
Allerdings würde ich das dann auch etwas anders machen. Und zwar im überschriebenen Constructor einfach den neuen Constructor aufrufen

Delphi-Quellcode:

constructor TTextEditor.Create(AOwner : TComponent); 
begin 
  Create(AOwner, StandardwertFuerlNEm);
end; 

//---------------------------------------------------------------------------------------------------------------------- 
// Klasse erzeugen - Konstruktor mit Parameter 
//---------------------------------------------------------------------------------------------------------------------- 
constructor TTextEditor.Create(AOwner : TComponent; lNEm : Boolean); 
begin 
  inherited Create(AOwner);   // <-- Welcher Konstruktor wird hier warum aufgerufen 
  lNotEmpty   := lNEm; 
  ActionCancel.Enabled  := not lNotEmpty; 
end;

[hsg]

Zitat von Robert Marquardt:

Brauchst du wirklich zwei Konstuktoren? Geht es nicht vielleicht nur mit dem zweiten und einem Parameter mit Defaultwert?

Es ist ganz klar was bei "inherited Create(AOwner)" aufgerufen wird. Es wird der Konstruktor von TMyForm aufgerufen. Falls Du dort nicht ebenfalls an den Konstruktoren spielst, hat diese Klasse nur einen Konstruktor. Selbst wenn es mehrere Konstruktoren gibt, sichert Delphi ab das es immer eindeutig bleibt. es gibt Fehlermeldungen falls die Deklaration der overloaded Konstruktoren/Methoden nicht eindeutig ist.

Sorry, dass sind meine C++-Altlasten, es ist mir klar, dass man das ganze auch anders lösen kann
Es wird nun langsam Licht im Dunkeln. TMyForm hat nur einen Konstruktor, von daher ist ab da für Delphi wieder alles klar.

Mir ist nur nicht klar, warum die Reihenfolge "overload; override;" für Delphi wichtig ist. Aber eigentlich verdeckt doch ein "overload" den originalen Konstruktor, oder nicht?
Von daher hätte ich erwartet, dass eine Kombination von beiden gar nicht zulässig sein dürfte, oder?

Zitat von SirThornberry:

überschreiben des alten constructors muss sein damit die ide weiterhin den TComponent-Nachfahren erzeugen kann.
Allerdings würde ich das dann auch etwas anders machen. Und zwar im überschriebenen Constructor einfach den neuen Constructor aufrufen

Delphi-Quellcode:

constructor TTextEditor.Create(AOwner : TComponent); 
begin 
  Create(AOwner, StandardwertFuerlNEm);
end;

Hmmmm, irgendwie habe fehlt mir bei diesem Konstrukt die (visuelle) Information, dass es sich dann um den Konstruktor der Elternklasse handelt.

[SirThornberry]

eben mit overload sagst du dem compiler das du eine zweite methode mit gleichem namen hast. Da du aber von einer klasse abgeleitet hast welche bereits eine virtuelle Methode mit dem Namen und den gleichen Parameter hat verdeckst du diese (daher auch die Warnung des Verdeckens). Mit einem Cast auf die Vorgängerklasse könnte man also weiterhin die verdeckte Methode aufrufen. Die Warnungen und Fehler haben alle ihre Rechtigkeit und sind auch logich (zumindest aus meiner Sicht)

[Robert Marquardt]

Man sollte mehrere Konstruktoren vermeiden. Man verliert dabei naemlich die Kompatibilitaet zum C++ Builder.
es gibt allerdings doch einige lustige Anwendungsmoeglichkeiten wie einen privaten Konstruktor. Man leitet den normalen Konstruktor ab und wirft im Konstruktor eine Exception. Damit wird der normale Konstruktor unbenutzbar. Create ist bei TObject naemlich public und die Sichtbarkeit wird man nicht mehr los. Nun kann man einen privaten Konstruktor implementieren: Somit ist es unmoeglich Objekte dieser Klasse in anderen Units zu instantiieren. Man braucht dann natuerlich eine Factory-Klasse in der gleichen Unit die das uebernimmt.

[SirThornberry]

wenn man aber eine exception im Standardconstructor wirft kann man die Componente nicht mehr automatisch erstellen lassen, also nicht mehr zur Designzeit auf dem Formular plazieren.

[hsg]

Zitat von SirThornberry:

eben mit overload sagst du dem compiler das du eine zweite methode mit gleichem namen hast. Da du aber von einer klasse abgeleitet hast welche bereits eine virtuelle Methode mit dem Namen und den gleichen Parameter hat verdeckst du diese (daher auch die Warnung des Verdeckens). Mit einem Cast auf die Vorgängerklasse könnte man also weiterhin die verdeckte Methode aufrufen. Die Warnungen und Fehler haben alle ihre Rechtigkeit und sind auch logich (zumindest aus meiner Sicht)

Ich habe aber in der "overload; override;" Variante keine Warnung, sondern der Compiler ist sehr glücklich mit meinem Source.
Habe ich nur das overload stehen, wird der originale Konstruktor verdeckt (deswegen dann ja auch die entsprechende Warnung), aber mit dem override sage ich doch normalerweise: da gibt es was in der Original-Klasse, bitte berücksichtige das auch....

Mein Verständnisproblem ist also momentan: verdecke ich den original Konstruktur (mittels overload) oder überschreibe ich ihn (mittels override).

Wenn ich mittels des ersten overload nur sage, da könnte evtl. noch eine Methode mit gleichem Namen geben, dann verstehe ich nicht das reintroduce im zweiten Konstruktor.

Ich glaube, ich schlafe erst einmal über dieses Thema (hab endlich Feierabend )

[Robert Marquardt]

Zitat von SirThornberry:

wenn man aber eine exception im Standardconstructor wirft kann man die Componente nicht mehr automatisch erstellen lassen, also nicht mehr zur Designzeit auf dem Formular plazieren.

Deshalb ist es fuer Komponenten auch nicht sinnvoll. Fuer Objekte aber schon.
Ich habe es bei meiner HID-Komponente gemacht, da dort ein DAU versucht hat Objekte, die ein Device repraesentieren, zu instantiieren. Das ist aber komplett sinnlos, da die Device-Objekte ausschliesslich von der Instanz der Controller-Komponente verwaltet werden.