(Falsche?) Warnung beim Überladen eines Konstruktors

[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.

[Jumpy]

Ich hatte codehunter so verstanden, dass wenn Basisklasse und Ableitung in verschiedenen Units sind, das nicht auftaucht.

[Neutral General]

Zitat von Jumpy:

Ich hatte codehunter so verstanden, dass wenn Basisklasse und Ableitung in verschiedenen Units sind, das nicht auftaucht.

Auch das funktioniert.

[Codehunter]

Zitat von Neutral General:

Zitat von Jumpy:

Ich hatte codehunter so verstanden, dass wenn Basisklasse und Ableitung in verschiedenen Units sind, das nicht auftaucht.

Auch das funktioniert.

Bei mir nicht (Seattle). Letzten Endes sind aber inzwischen alle Möglichkeiten genannt, das Problem zu beseitigen. Die Kombination von reintroduce und overload dürfte den Zweck erfüllen, wenn auch mit dem Nachteil dass man den elterlichen Konstruktor overriden und als inherited-Stub anlegen muss. Schön geht halt anders.