héritage et appel de fonction dans constructeur

Bonjour à tous,

prenons le code suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class Pere { public: Pere(){ cout << "ctor pere" << endl; f(); } virtual void f() { cout << "f() pere" << endl; }   };   class Fille: public Pere { public: Fille() { cout << "ctor fille" << endl; } void f() { cout << "f() fille" << endl; } };

---

Nous voyons que dans le constructeur de Pere, la fonction f() est appelée. Pourquoi, lorsqu'on crée un objet fille (Fille fille; ), c'est la fonction f() du père qui est appelé dans le constructeur de Pere, et pas la fonction f() de la classe Fille? Normalement, le compilo "sait" qu'il est en train d'instancier une classe Fille, pourquoi alors appelle-t-il la fonction f() de Père?

Pour info, le code ci-dessus, lors d'une création d'une instance de Fille, donne l'output suivant:

Citation:

---

ctor pere
f() pere
ctor fille

---

Et question subsidiaire, pourquoi si dans la classe Pere, on déclare f() comme virtuelle pure, ça ne compile même pas?

Salut,

Simplement, parce que, si la fille connait le père, le père ne connait pas la fille...

L'héritage est une relation "à sens unique", ainsi que le démontre la nécessité du transtypage lorsque l'on part d'un objet du type parent et que l'on souhaite récupérer le type réel enfant.

Toute la logique habituellement mise en oeuvre tend à montrer cet état de fait, bien que le programmeur puisse ne pas en avoir conscience:

• la classe parent ne connait pas les membres (qu'il s'agisse de variables ou de fonction membre)de la classe enfant
• Tu peux faire passer un objet de la classe fille pour un objet de la classe parent sans prendre de précaution particulière, mais
• lorsque tu souhaite récupérer le type d'origine (réel, enfant) au départ d'un objet qui passe pour être du type parent, tu dois recourir au transtypage ("cast")

[EDIT] Pour répondre à la question subsidiaire que j'avais zapée, c'est, justement, parce qu'une fonction virtuelle pure n'est, par définition, pas définie pour le type parent, et que, le parent ne connaissant pas ses enfants, il n'y a aucun moyen de faire la relation avec les (re)définitions présentes dans les types enfants ;)

[EDIT 2]Ce n'est d'ailleurs pas un hasard si, en UML, la relation d'héritage est représentée par une flèche (dont la pointe est un triange vide) orientée vers la classe parent ;)

Okay, je comprends, merci chef :ccool:
Et sinon, à part une factory, quelles sont les solutions pour pallier à ce problème?

Citation:

---

Envoyé par r0d

Okay, je comprends, merci chef :ccool:
Et sinon, à part une factory, quelles sont les solutions pour pallier à ce problème?

---

Heu... appeler la fonction depuis le constructeur de classe enfant, par exemple :D

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Base { public: Base() { foo(); // ne fonctionne pas, surtout si foo est virtuelle pure // au mieux: appelle Base::foo } virtual void foo(); }; class Derived : public Base { public: Derived { foo(); // appelle bel et bien Derived::foo } virtual void foo(); };

---

Salut vielle branche.

Citation:

---

Envoyé par r0d

Okay, je comprends, merci chef :ccool:
Et sinon, à part une factory, quelles sont les solutions pour pallier à ce problème?

---

Ce que j'ai capté , les fonction virtual vont être géré par une sorte de tableau de pointeur de fonction.
lorsque tu créé la classe Fille, cette création va être exécuté en deux temps:
1- la partie classe père est créé. le pointeur de fonction correspondant à f() pointe sur parent::f();
2- la partie classe fille est créé et le pointeurs de fonction correspondant à f() est mise à jour => le pointeur de fonction correspondant à f() pointe sur fille::f();

Donc il est impossible d'appeler une fonction surchargé par fille dans le constructeur de parent. Et la meilleur raison que j'ai trouvé est parce que la partie fille n'exister pas encore :marteau:

Y as pas une QR écrit par jolyloïc sur cela?

Au fait, il est d'ailleurs peut être temps de se rappeler de LSP et de ses implications...:

Logiquement, si tu décide d'invoquer un comportement donné au moment de la construction d'un objet parent, c'est, fatalement, parce qu'il est cohérent,adapté et valide à / pour l'objet parent.

LSP aidant, tu dois veiller à ce que le comportement observé chez le parent reste valide chez l'enfant, quitte à ce qu'il ne soit pas adapté.

Si, effectivement, le comportement reste valide mais devient inadapté pour l'enfant, il s'agira donc, quoi qu'il arrive, d'appeler (à nouveau :question:) le comportement en question au départ d'un objet dont on sait qu'il est du type dynamique de l'enfant ;)

Et on pourrait pas faire un truc bien affreux à base de reinterpret_cast avec RTTI?

Citation:

---

Envoyé par r0d

Et on pourrait pas faire un truc bien affreux à base de reinterpret_cast avec RTTI?

---

L'avantage du C++ c'est que l'on peut, virtuellement, tout faire, y compris les choses les plus affreuses..

Mais, entre le fait de pouvoir faire quelque chose et le fait de décider de le faire, il y a souvent une marge qu'il s'agit vraiment de considérer avec la plus grande attention :P

Ceci dit, selon moi, le minimum nécessaire pour que le RTTI soit en mesure de déterminer le type réel dans le constructeur de la classe de base risque de ne pas encore etre accessible...

Alors, je dirais qu'il est *peut être* possible de partir sur une telle horreur, mais je trouve l'idée tellement horrible que je ne m'y risquerais jamais ;)

Maintenant, ce n'est pas à moi de décider pour toi ;)

Salut,

Citation:

---

Envoyé par yan

Et la meilleur raison que j'ai trouvé est parce que la partie fille n'exister pas encore :marteau:

---

D'un point de vue strictement technique, je crois que c'est effectivement la meilleur raison. Fille n'existe pas encore quand Pere se construit. Et à l'inverse, Fille n'existe plus quand Pere se détruit.
D'un point de vue conception, pourquoi diable Pere aurait des exigences vis à vis de la construction de Fille ? Pere doit construire un objet dans lequel ses invariants sont respectés. A charge de Fille d'en faire de même pour ses propres invariants.

Citation:

---

Envoyé par r0d

Okay, je comprends, merci chef :ccool:
Et sinon, à part une factory, quelles sont les solutions pour pallier à ce problème?

---

Le pattern Monteur ?

Sinon, tu peux toujours tenter un truc de ce genre (CRTP inside :aie:) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

template <class derived_widget> class widget { public: // ... void show() { static_cast<derived_widget*>(this)->show(); } // ... };   class button : public widget<button> { public: void show() { std::cout << "Button" << std::endl; } // ... };   class textfield : public widget<textfield> { public: void show() { std::cout << "Textfield" << std::endl; } // ... };

---

Donc, en gros, paramétrer la classe mère de sorte à ce qu'elle "connaisse" la classe fille. Merci à loufoque pour son apport sur le sujet, qui paraîtra dans la prochaine màj de la FAQ C++ :)

8O jolie. mais pas sure que cela marche dans le constructeur.
C'est ce que l'on appel du polymorphisme statique?

Le polymorphisme statique c'est juste le polymorphisme attaché aux templates (en général, même si c'est plus général je pense).

Ca peut aussi bien se manifester comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

template <class Animal> struct FaiseurDeBruit { static void f() { Animal::bruit(); } };   struct Chien { static void bruit() { std::cout << "Ouaf" << std::endl; } };   // ... FaiseurDeBruit<Chien>::f(); // affiche "Ouaf"

---

Quand au soucis dans le constructeur, je ne sais effectivement pas si ça marchera étant donné que la fille n'est pas encore construite, donc dans tous les cas, c'est moyen. Il faudrait séparer l'initialisation en 2 parties pour que dans une méthode init() ou autre, on appelle fille::f(). Ca rejoint un peu l'idiome NVI d'ailleurs, en quelques sortes.

Citation:

---

Et la meilleur raison que j'ai trouvé est parce que la partie fille n'exister pas encore

---

D'ailleurs il faut faire attention avec ce méchanisme d'appel en cascade des constructeur.


J'ai eu le problème sur une appli il n'y a pas si longtemp ou le père allait s'enregistrer quelque part pendant sa construction et commençait à se faire manipulé par d'autres objets alors que le fils n'avait pas finit d'etre construit.

C'etait un core dump assuré en multithread.

Anh première fois que je vois une réelle utilité au CRTP. (enfin un truc qui saute aux yeux jveux dire)

le CRTP est plus rapide que les fonction virtuel?
Quel est l'avantage?

Ben le CRTP c'est des templates hein, donc tout est au compile time. Les fonctions virtuels y'a une indirection en plus avec la vtable.

Citation:

---

Envoyé par Goten

Ben le CRTP c'est des templates hein, donc tout est au compile time. Les fonctions virtuels y'a une indirection en plus avec la vtable.

---

En faite, je voie pas quel est la différence avec un héritage sans virtual...
Je vais me chercher des exemple, je pense.

Citation:

---

Envoyé par yan

Je vais me chercher des exemple, je pense.

---

Pour ceux que cela intéresse
http://www.lrde.epita.fr/dload/techrep/techrep9903.pdf

Citation:

---

Envoyé par r0d

Et question subsidiaire, pourquoi si dans la classe Pere, on déclare f() comme virtuelle pure, ça ne compile même pas?

---

Parce que tu as la chance d'avoir un compilateur qui préfère ça à un plantage lors de l'exécution ? :) Remarque, si tu déclares la fonction virtuelle pure, mais que tu la définis quand même (oui, c'est totalement légal, virtuel pure ne signifie pas "non implémentée", mais implémentation non obligatoire + classe abstraite tant que pas redéfini en non pure), le code devrait marcher et se comporter comme dans ton exemple.

Citation:

---

Envoyé par yan

Y as pas une QR écrit par jolyloïc sur cela?

---

Si, mais elle n'est pas encore publiée.

Citation:

---

Puis-je appeler des fonctions virtuelles dans le constructeur (ou le destructeur)
Oui, c'est possible, mais attention, ça ne fait pas toujours ce qu'on pense. La règle est que le type dynamique d'une variable en cours de construction est celui du constructeur qui est en train d'être exécuté. Pour bien comprendre ce qui se passe, il faut donc revenir sur la différence entre le type statique d'une variable, et son type dynamique.

Prenons par exemple trois classes, C qui dérive de B qui dérive de A. Par exemple, dans :

A* a = new B();

La variable a possède comme type statique (son type déclaré dans le programme) A*. Par contre, son type dynamique est B*. Une fonction virtuelle est simplement une fonction dont on va chercher le code en utilisant le type dynamique de la variable, au lieu de son type statique, comme une fonction classique.

Maintenant, quand on crée un objet de type C, les choses se passent ainsi :

* On alloue assez de mémoire pour un objet de la taille de C.
* On initialise la sous partie correspondant à A de l'objet
* On appelle le corps du constructeur de A. Pendant cet appel, l'objet crée a pour type dynamique A.
* On initialise la sous partie correspondant à B de l'objet
* On appelle le corps du constructeur de B. Pendant cet appel, l'objet crée a pour type dynamique B.
* On initialise la sous partie correspondant à C de l'objet
* On appelle le corps du constructeur de C. Pendant cet appel, l'objet crée a pour type dynamique C.

Donc, dans le corps du constructeur de la classe B, un appel d'une fonction virtuelle appellera la version de la fonction définie dans la classe B (ou à défaut celle définie dans A si la fonction n'a pas été définie dans B), et non pas celle définie dans la classe C.

D'ailleurs, si la fonction est virtuelle pure dans B, ça causera quelques problèmes, puisqu'on tentera alors d'appeler une fonction qui n'existe pas. En général, le programme va planter, si on a de la chance, il affichera une message du style "Pure function called".

La problèmatique est exactement la même pour les destructeurs, mais dans l'ordre inverse.

Pourquoi cette règle ? Une fonction définie dans C a accès aux données membre de C. Or, on a vu que au moment où on exécute l'appel au corps du constructeur de B, ces dernières ne sont pas encore crées. On a donc préférer jouer la sécurité.

---

Au passage, attention à ceux d'entre nous qui programment pour le Framework .Net: Pour des raisons inhérentes au GC, ils doivent balancer tout cela par la fenêtre quand ils manipulent des types managés.