Aufrufen virtueller Funktionen innerhalb von Konstruktoren

Angenommen, ich habe zwei C++-Klassen:

class A
{
public:
  A() { fn(); }

  virtual void fn() { _n = 1; }
  int getn() { return _n; }

protected:
  int _n;
};

class B : public A
{
public:
  B() : A() {}

  virtual void fn() { _n = 2; }
};

Wenn ich folgenden Code schreibe:

int main()
{
  B b;
  int n = b.getn();
}

Das könnte man erwarten n ist auf 2 eingestellt.

Es stellt sich heraus, dass n auf 1 gesetzt. Warum?

Das Aufrufen virtueller Funktionen von einem Konstruktor oder Destruktor ist gefährlich und sollte nach Möglichkeit vermieden werden. Alle C++-Implementierungen sollten die Version der Funktion aufrufen, die auf der Ebene der Hierarchie im aktuellen Konstruktor definiert ist, und nicht weiter.

Die C++ FAQ Lite behandelt dies in Abschnitt 23.7 ziemlich ausführlich. Ich schlage vor, das (und den Rest der FAQ) für ein Follow-up zu lesen.

Auszug:

[…] In einem Konstruktor ist der virtuelle Aufrufmechanismus deaktiviert, da das Überschreiben von abgeleiteten Klassen noch nicht stattgefunden hat. Objekte werden von der Basis nach oben konstruiert, „Basis vor Ableitung“.

[…]

Die Zerstörung erfolgt „abgeleitete Klasse vor Basisklasse“, sodass sich virtuelle Funktionen wie in Konstruktoren verhalten: Es werden nur die lokalen Definitionen verwendet – und es werden keine Aufrufe an überschreibende Funktionen vorgenommen, um zu vermeiden, dass der (jetzt zerstörte) abgeleitete Klassenteil des Objekts berührt wird.

BEARBEITEN Am meisten korrigiert (danke litb)

Der Aufruf einer polymorphen Funktion von einem Konstruktor ist in den meisten OO-Sprachen ein Rezept für eine Katastrophe. Wenn diese Situation auftritt, funktionieren verschiedene Sprachen unterschiedlich.

Das grundlegende Problem besteht darin, dass in allen Sprachen der Basistyp bzw. die Basistypen vor dem abgeleiteten Typ konstruiert werden müssen. Das Problem ist nun, was es bedeutet, eine polymorphe Methode vom Konstruktor aus aufzurufen. Was erwartest du, wie es sich verhalten wird? Es gibt zwei Ansätze: Rufen Sie die Methode auf der Basisebene auf (C++-Stil) oder rufen Sie die polymorphe Methode für ein nicht konstruiertes Objekt am unteren Ende der Hierarchie auf (Java-Weg).

In C++ erstellt die Basisklasse ihre Version der virtuellen Methodentabelle, bevor sie in ihre eigene Konstruktion eintritt. An diesem Punkt führt ein Aufruf der virtuellen Methode dazu, dass die Basisversion der Methode aufgerufen oder eine erzeugt wird rein virtuelle Methode aufgerufen falls es auf dieser Ebene der Hierarchie keine Implementierung gibt. Nachdem die Base vollständig erstellt wurde, beginnt der Compiler mit dem Erstellen der Derived-Klasse und überschreibt die Methodenzeiger, um auf die Implementierungen in der nächsten Ebene der Hierarchie zu zeigen.

class Base {
public:
   Base() { f(); }
   virtual void f() { std::cout << "Base" << std::endl; } 
};
class Derived : public Base
{
public:
   Derived() : Base() {}
   virtual void f() { std::cout << "Derived" << std::endl; }
};
int main() {
   Derived d;
}
// outputs: "Base" as the vtable still points to Base::f() when Base::Base() is run

In Java erstellt der Compiler das virtuelle Tabellenäquivalent im allerersten Konstruktionsschritt, bevor er in den Basiskonstruktor oder den abgeleiteten Konstruktor eintritt. Die Implikationen sind anders (und für meinen Geschmack gefährlicher). Wenn der Konstruktor der Basisklasse eine Methode aufruft, die in der abgeleiteten Klasse überschrieben wird, wird der Aufruf tatsächlich auf der abgeleiteten Ebene behandelt, indem eine Methode für ein nicht konstruiertes Objekt aufgerufen wird, was zu unerwarteten Ergebnissen führt. Alle Attribute der abgeleiteten Klasse, die innerhalb des Konstruktorblocks initialisiert werden, sind noch nicht initialisiert, einschließlich der „final“-Attribute. Elemente mit einem auf Klassenebene definierten Standardwert haben diesen Wert.

public class Base {
   public Base() { polymorphic(); }
   public void polymorphic() { 
      System.out.println( "Base" );
   }
}
public class Derived extends Base
{
   final int x;
   public Derived( int value ) {
      x = value;
      polymorphic();
   }
   public void polymorphic() {
      System.out.println( "Derived: " + x ); 
   }
   public static void main( String args[] ) {
      Derived d = new Derived( 5 );
   }
}
// outputs: Derived 0
//          Derived 5
// ... so much for final attributes never changing :P

Wie Sie sehen, ruft ein polymorphes (virtuell in der C++-Terminologie) Methoden ist eine häufige Fehlerquelle. In C++ haben Sie zumindest die Garantie, dass es niemals eine Methode für ein noch nicht konstruiertes Objekt aufruft …

Der Grund dafür ist, dass C++-Objekte wie Zwiebeln aufgebaut sind, von innen nach außen. Basisklassen werden vor abgeleiteten Klassen erstellt. Bevor also ein B gemacht werden kann, muss ein A gemacht werden. Wenn der Konstruktor von A aufgerufen wird, ist es noch kein B, sodass die virtuelle Funktionstabelle immer noch den Eintrag für die Kopie von fn() von A enthält.

Die C++ FAQ Lite Deckt das ziemlich gut ab:

Während des Aufrufs des Basisklassenkonstruktors ist das Objekt im Wesentlichen noch nicht vom abgeleiteten Typ, und daher wird die Implementierung der virtuellen Funktion des Basistyps aufgerufen und nicht die des abgeleiteten Typs.

Eine Lösung für Ihr Problem besteht darin, Factory-Methoden zum Erstellen Ihres Objekts zu verwenden.

• Definieren Sie eine gemeinsame Basisklasse für Ihre Klassenhierarchie, die eine virtuelle Methode afterConstruction() enthält:

class Object
{
public:
  virtual void afterConstruction() {}
  // ...
};

• Definieren Sie eine Factory-Methode:

template< class C >
C* factoryNew()
{
  C* pObject = new C();
  pObject->afterConstruction();

  return pObject;
}

• Verwenden Sie es wie folgt:

class MyClass : public Object 
{
public:
  virtual void afterConstruction()
  {
    // do something.
  }
  // ...
};

MyClass* pMyObject = factoryNew();

Andere Antworten haben bereits erklärt, warum virtual Funktionsaufrufe funktionieren nicht wie erwartet, wenn sie von einem Konstruktor aufgerufen werden. Ich möchte stattdessen eine andere mögliche Problemumgehung vorschlagen, um ein polymorphes Verhalten vom Konstruktor eines Basistyps zu erhalten.

Durch Hinzufügen eines Vorlagenkonstruktors zum Basistyp, sodass das Vorlagenargument immer als abgeleiteter Typ abgeleitet wird, ist es möglich, den konkreten Typ des abgeleiteten Typs zu erkennen. Von dort aus können Sie anrufen static Memberfunktionen für diesen abgeleiteten Typ.

Diese Lösung erlaubt keine Nicht-static Member-Funktionen aufgerufen werden. Während die Ausführung im Konstruktor des Basistyps erfolgt, hatte der Konstruktor des abgeleiteten Typs noch nicht einmal Zeit, seine Member-Initialisierungsliste durchzugehen. Der Teil des abgeleiteten Typs der zu erstellenden Instanz hat noch nicht damit begonnen, ihn zu initialisieren. Und da nicht-static Elementfunktionen interagieren mit ziemlicher Sicherheit mit Datenelementen, die ungewöhnlich wären will um die Nicht-static Memberfunktionen aus dem Konstruktor des Basistyps.

Hier ist eine Beispielimplementierung:

#include <iostream>
#include <string>

struct Base {
protected:
    template<class T>
    explicit Base(const T*) : class_name(T::Name())
    {
        std::cout << class_name << " created\n";
    }

public:
    Base() : class_name(Name())
    {
        std::cout << class_name << " created\n";
    }


    virtual ~Base() {
        std::cout << class_name << " destroyed\n";
    }

    static std::string Name() {
        return "Base";
    }

private:
    std::string class_name;
};


struct Derived : public Base
{   
    Derived() : Base(this) {} // `this` is used to allow Base::Base<T> to deduce T

    static std::string Name() {
        return "Derived";
    }
};

int main(int argc, const char *argv[]) {

    Derived{};  // Create and destroy a Derived
    Base{};     // Create and destroy a Base

    return 0;
}

Dieses Beispiel sollte gedruckt werden

Derived created
Derived destroyed
Base created
Base destroyed

Wenn ein Derived aufgebaut ist, die Base Das Verhalten des Konstruktors hängt vom tatsächlichen dynamischen Typ des zu erstellenden Objekts ab.

Wie bereits erwähnt, werden die Objekte von der Basis nach unten nach der Konstruktion erstellt. Wenn das Basisobjekt erstellt wird, ist das abgeleitete Objekt noch nicht vorhanden, sodass eine virtuelle Funktionsüberschreibung nicht funktionieren kann.

Dies kann jedoch mit polymorphen Gettern gelöst werden, die verwenden statischer Polymorphismus Anstelle von virtuellen Funktionen, wenn Ihre Getter Konstanten zurückgeben oder anderweitig in einer statischen Elementfunktion ausgedrückt werden können, verwendet dieses Beispiel CRTP (https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern).

template<typename DerivedClass>
class Base
{
public:
    inline Base() :
    foo(DerivedClass::getFoo())
    {}

    inline int fooSq() {
        return foo * foo;
    }

    const int foo;
};

class A : public Base<A>
{
public:
    inline static int getFoo() { return 1; }
};

class B : public Base<B>
{
public:
    inline static int getFoo() { return 2; }
};

class C : public Base<C>
{
public:
    inline static int getFoo() { return 3; }
};

int main()
{
    A a;
    B b;
    C c;

    std::cout << a.fooSq() << ", " << b.fooSq() << ", " << c.fooSq() << std::endl;

    return 0;
}

Durch die Verwendung von statischem Polymorphismus weiß die Basisklasse, welcher Getter der Klasse aufgerufen werden soll, da die Informationen zur Kompilierzeit bereitgestellt werden.