(Falsche?) Warnung beim Überladen eines Konstruktors

[Neutral General]

Hallo,

Habe vereinfacht folgende Situation (Delphi 10.3.0):

Delphi-Quellcode:

type
  TBasis = class
  public
    constructor Create(AOwner: TComponent); virtual; 
  end;

  TAbleitung = class(TBasis)
  public
    constructor Create(AOwner: TComponent; A, B: String); overload; // [dcc32 Warnung] Unit4.pas(24): W1010 Methode 'Create' verbirgt virtuelle Methode vom Basistyp 'TBasis'
  end;

Ich verstehe nicht warum da eine Warnung kommt. Ich füge in der Ableitung einfach einen zweiten constructor per overload hinzu.
Der sollte nichts verbergen und auch wenn ich das teste, kann ich im Code beide constructoren aufrufen (funktioniert auch zur Laufzeit):

Delphi-Quellcode:

// Beides compiliert und läuft.
var ableitung: TAbleitung;
begin
  ableitung := TAbleitung.Create(nil);
  ableitung := TAbleitung.Create(nil, 'A', 'B');

Die Codevervollständigung zeigt korrekt beide Überladungen an, beide Überladungen kompilieren und verhalten sich auch zur Laufzeit wie man das erwartet würde.
Warum also dann die Warnung? Gibts da irgendwas was ich übersehe oder ist die Warnung an der Stelle (wie ich vermute) einfach falsch?

Wenn ich den constructor in TBasis NICHT virtuell mache, dann meckert der Compiler übrigens nicht.

[Schokohase]

reintroduce http://docwiki.embarcadero.com/RADSt...thoden_(Delphi)

[Neutral General]

Zitat von Schokohase:

reintroduce http://docwiki.embarcadero.com/RADSt...thoden_(Delphi)

Ich kenne reintroduce, aber das ist ein ganz anderer Fall.
Es geht hier ja explizit darum einen 2. Konstruktor hinzuzufügen (eine Überladung) und nicht den Konstruktor der Basisklasse mit reintroduce zu überdecken.
Und das klappt ja auch - nur halt mit einer Warnung die ich nicht nachvollziehen kann.

[Schokohase]

Delphi-Quellcode:

type
  TBasis = class
  public
    constructor Create(AOwner: TComponent); virtual;
  end;

  TAbleitung = class(TBasis)
  public
    constructor Create(AOwner: TComponent); overload; override;
    constructor Create(AOwner: TComponent; A,B: string); reintroduce; overload;
  end;

{ TBasis }

constructor TBasis.Create(AOwner: TComponent);
begin
  inherited Create;

end;

{ TAbleitung }

constructor TAbleitung.Create(AOwner: TComponent);
begin
  inherited;

end;

constructor TAbleitung.Create(AOwner:TComponent; A,B: string);
begin
  inherited Create(AOwner);

end;

[Neutral General]

Dann hab ich für TAbleitung 3 Konstruktoren (2x (AOwner: TComponent)).

Aber so klappt es:

Delphi-Quellcode:

type
  TBasis = class
  public
    constructor Create(AOwner: TComponent); virtual;
  end;

  TAbleitung = class(TBasis)
  public
    constructor Create(AOwner: TComponent; A,B: string); reintroduce; overload;
  end;

[Schokohase]

Zitat von Neutral General:

Dann hab ich für TAbleitung 3 Konstruktoren (2x (AOwner: TComponent)).

Jupp, so hatte ich es auch zuerst, aber dann hat mein Rio rumgesponnen und zeigte mir nur diesen einen Konstruktor an.

Ich halte es eh für seltsam dass die Konstruktoren automatisch weitervererbt werden. Das machen andere Sprachen anders (und mMn auch besser).

Egal, es läuft ja (irgendwie).

[Der schöne Günther]

Zitat von Schokohase:

Egal, es läuft ja (irgendwie).

The Delphi Way of Life ™

[Codehunter]

Ähm... Wer sagt denn dass ein Constructor unbedingt "Create" heißen muss? Nenn den in der Kindklasse eben "CreateNew", was ja nicht unüblich ist.

Oder alternativ, den Konstruktor der Basisklasse einfach gar nicht erst virtual deklarieren. Die besagte Compilerwarnung hat schon ihre Berechtigung. Denn es hindert dich ja nichts daran, in der Kindklasse einen Konstruktor mit identischer Parameterliste wie in der Elternklasse zu deklarieren. Spätestens dann hättest du ein Scope-Problem.

Der scheinbar vererbte Konstruktor wird dir auch nur in der selben Unit in beiden Varianten in der Codevervollständigung angezeigt. In einer anderen Unit erscheint nur der Konstruktor der Kindklasse. Ist wohl die selbe "Baustelle" wie die Tatsache, dass man in der selben Unit auch in Kindklassen auf private-Variablen der Elternklasse zugreifen kann.

Besser man gewöhnt sich so einen Schluderladen aus überladenen virtuellen Konstruktoren gar nicht erst an. Denn in der Praxis kann man meistens nur einen davon gebrauchen weil der andere die Kindklasse gar nicht richtig initialisiert.

[Stevie]

Hat Himitsu schon vor Jahren mal eingetragen und wurde als "Works as expected" geschlossen: https://quality.embarcadero.com/browse/RSP-11165

[Neutral General]

Zitat von Codehunter:

Ähm... Wer sagt denn dass ein Constructor unbedingt "Create" heißen muss? Nenn den in der Kindklasse eben "CreateNew", was ja nicht unüblich ist.

Technisch gesehen hast du Recht. In der Praxis wird mir schlecht wenn ich Konstruktoren sehe, die nicht "Create" heißen.

Zitat von Codehunter:

Oder alternativ, den Konstruktor der Basisklasse einfach gar nicht erst virtual deklarieren. Die besagte Compilerwarnung hat schon ihre Berechtigung. Denn es hindert dich ja nichts daran, in der Kindklasse einen Konstruktor mit identischer Parameterliste wie in der Elternklasse zu deklarieren. Spätestens dann hättest du ein Scope-Problem.

Das hier ist nur ein Beispiel. Im Original ist TBasis eine Ableitung von TComponent, bei der der constructor Create(AOwner: TComponent) nunmal virtuell ist.
Die Compilerwarnung hat NUR DANN eine Berechtigung wenn ich in der Ableitung tatsächlich einen Konstruktor definiere mit den gleichen Parametern wie er schon in der/einer Elternklasse existiert.
Das ist aber hier nicht der Fall, daher kein Scope Problem und keinen Grund für die Warnung.

Zitat von Codehunter:

Der scheinbar vererbte Konstruktor wird dir auch nur in der selben Unit in beiden Varianten in der Codevervollständigung angezeigt. In einer anderen Unit erscheint nur der Konstruktor der Kindklasse. Ist wohl die selbe "Baustelle" wie die Tatsache, dass man in der selben Unit auch in Kindklassen auf private-Variablen der Elternklasse zugreifen kann.

Das ist schlichtweg falsch:

Formular:


Unit4:

Zitat von Codehunter:

Besser man gewöhnt sich so einen Schluderladen aus überladenen virtuellen Konstruktoren gar nicht erst an. Denn in der Praxis kann man meistens nur einen davon gebrauchen weil der andere die Kindklasse gar nicht richtig initialisiert.

Das kann man so auch nicht verallgemeinern.
In den meisten Fällen hast du Recht, aber es gibt eben auch Fälle wo der Konstruktor des Kinds nur ein "Bonus" ist und auch der Elternkonstruktor das Objekt ausreichend initialisiert.