Warum virtual / override bei destructor / constructor?

[Stevie]

Was Zacherl gezeigt hat, sieht man zum Beispiel bei TComponent. Dort ist der Konstructor virtual, was benötigt wird, wenn vom Streaming Mechanismus (Form wird aus dfm geladen) die ganzen Komponenten erstellt werden.

Wäre TObject.Create virtual, müsste man jegliche Klasse über TClass erzeugen können, obwohl diese Klasse möglicherweise gar keinen parameterlosen Konstruktor haben soll.
Aktuell gibt es nur den kleinen haken, dass ein Create auf einer TClass variable fest TObject.Create aufruft, was weitaus weniger schlimm ist.

Zitat von HJay:

Warum kann man den "constructor create" überschreiben, ohne "reintroduce" angeben zu müssen? Müsste das nicht kollidieren?

Verwechsle nicht die Begriffe, "überschreiben" (override) kann man nur virtuelle Methoden - ein reintroduce ist lediglich ein Hinweis an den Compiler nach dem Motto - ich weiß, was ich tue (damit der keine Warning W1010 generiert). Alles andere ist verdecken einer Methode. Und da TObject.Create nunmal nicht virtual ist, gibts auch kein reintroduce.

Mir scheint, da sind noch ein paar Wissenslücken bzgl OOP/Polymorphie verhanden, die das Verständnis etwas erschweren.

P.S. Da sieht man mal, warum C# es erforderlich macht, auf jeder Klasse explizit einen Konstruktor zu definieren (selbst wenn er nix macht). Weil implizit einen erben nur verwirrt und zu Defekten führen kann.