Méthode virtuelle d'appel immédiatement après la construction

Question

Je dois appeler une méthode virtuelle pour toutes les classes dérivées d'une classe de base de base donnée juste après la construction de l'objet dérivé. Mais le faire dans le constructeur de la classe de base se traduira par un pur appel de méthode virtuelle

Voici un exemple simplifié:

struct Loader { 
    int get(int index) { return 0; } 
}; 

struct Base{ 
    Base() { 
     Loader l; 
     load(l); // <-- pure virtual call! 
    } 
    virtual void load(Loader &) = 0; 
}; 

struct Derived: public Base { 
    int value; 
    void load(Loader &l) { 
     value = Loader.get(0); 
    } 
}; 

Je peux appeler load au constructeur Derived, mais Derived ne pouvait pas savoir comment pour créer un chargeur. Des idées/solutions de contournement?

Answer 1

Utilisez le modèle PIMPL:

template<typename T> 
class Pimpl 
{ 
    public: 
     Pimpl() 
     { 
      // At this point the object you have created is fully constructed. 
      // So now you can call the virtual method on it. 
      object.load(); 
     } 
     T* operator->() 
     { 
      // Use the pointer notation to get access to your object 
      // and its members. 
      return &object; 
     } 
    private: 
     T object; // Not technically a pointer 
         // But otherwise the pattern is the same. 
         // Modify to your needs. 
}; 

int main() 
{ 
    Pimpl<Derived> x; 
    x->doStuff(); 
} 

Answer 2

De nombreux frameworks connus (comme MFC) le font: Ils font une fonction-membre (virtuelle) Init() ou Create() et y font l'initialisation puis mandatent dans la documentation que l'utilisateur appelle. Je sais que vous n'aimerez pas cette idée, mais vous ne pouvez pas appeler une méthode virtuelle d'un constructeur et vous attendre à un comportement polymorphe, quelle que soit la pureté des méthodes ...

Answer 3

Le problème est que la construction de la classe de base se produit avant que la classe dérivée soit entièrement construite. Vous devez soit appeler « charge » de la classe dérivée, initialise motifs indépendants une fonction de membre virtuel différent ou créer une fonction d'aide pour ce faire:

Base* CreateDerived() 
{ 
    Base* pRet = new Derived; 
    pRet->Load(); 
    return pRet; 
} 

Answer 4

Le C++ FAQ appelle ce problème DBDI, Liaison dynamique pendant la construction. Principalement, le problème est d'éviter la construction en deux phases du mal préconisée dans d'autres réponses ici. C'est une sorte de "ma" FAQ - j'ai convaincu Marshall de l'ajouter. Cependant, Marshall l'a pris sur lui est très général (ce qui est bon pour une FAQ), alors que j'étais plus préoccupé par le motif de conception/codage particulier. Ainsi, au lieu de vous envoyer à la FAQ, je vous envoie sur mon propre blog, l'article "How to avoid post-construction by using Parts Factories", qui renvoie à l'article correspondant de la FAQ, mais discute en profondeur du modèle.

Vous pouvez simplement sauter les deux premiers paragraphes ...

je sorte de glosé là-bas. :-)

Vive & HTH.,

Answer 5

Pouvez-vous pas ajouter une méthode getLoader() dans votre classe Base pour que DerivedClass constructeur peut l'appeler sur this pour obtenir un Loader? As DerivedClass constructeur sera appelé après Base constructeur de classe, cela devrait fonctionner correctement.

Answer 6

Il est difficile de donner des conseils, sauf si vous nous dites ce que vous essayez d'accomplir, plutôt que comment. Je trouve qu'il est généralement préférable de construire de tels objets à partir d'une usine, qui va charger les données requises à l'avance, puis passer les données dans le constructeur de l'objet.

Answer 7

Il y a plusieurs façons de corriger cette situation, voici 1 suggestion adapter dans votre cadre fourni

struct Loader { 
    int get(int index) { return 0; } 
}; 

struct Base{ 
    Base() { 
    } 
    Loader & getLoader(); 
private: 
    Loader l; 
}; 

struct Derived: public Base { 
    int value; 
    Derived() { 
     value = getLoader().get(0); 
    } 
}; 

Answer 8

Cela peut être un peu tard après d'autres réponses, mais je vais donner encore un essai.

Vous peut mettre en œuvre cette en toute sécurité et sans changer les classes dérivées. Cependant, vous devrez changer et utiliser de toutes ces classes, ce qui pourrait être bien pire, selon votre scénario. Si vous concevez toujours, alors ceci pourrait être une alternative viable.

Fondamentalement, vous pouvez appliquer le curiously recurring template pattern et injecter le code d'initialisation après que le constructeur est appelé. En outre, si vous le faites comme je l'ai écrit ci-dessous, vous pouvez même protéger load d'être appelé deux fois. Franchement, cependant, je considérerais un design alternatif si vous le pouvez. Déplacez le code de load à vos constructeurs et de fournir le chargeur comme un argument de référence en défaut comme suit:

struct Derived : public Base { 
    Derived (Loader& loader = Loader()) { ... } 
}; 

De cette façon, vous évitez complètement le problème.

Résumé: vos choix sont les suivants:

1. Si vous n'êtes pas limité par des contraintes externes et ne dispose pas d'une base de code en fonction de ce vaste, changer votre conception pour quelque chose plus sûr.
2. Si vous souhaitez conserver load comme il est et ne pas trop modifier vos classes, mais que vous êtes prêt à payer le prix de toutes les instanciations, appliquez CRTP comme proposé ci-dessus.
3. Si vous insistez pour être principalement rétrocompatible avec le code client existant, vous devrez modifier vos classes pour utiliser un PIMPL comme d'autres l'ont suggéré ou vivre avec le problème existant.