Conteneur d'objets enfants

Bonjour !

J'ai besoin d'un conteneur (de préférence associatif (std::map, ...)) permettant de stocker des objets héritant tous d'une même classe tout en conservant les données des objets enfants dans le but de faire quelque chose comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

#include <map> #include <string>   class Parent { public: Parent(); void FonctionParent(); };   class Enfant : public Parent { public: Enfant(); void FonctionEnfant(); };   class structure { public: void AjouterObjet(std::string nom, Parent objet) { m_Objets[nom] = objet; } Parent RecupObjet(std::string nom) { return m_Objets[nom]; }   private: std::map < std::string, Parent> m_Objets; };   int main() { structure a; Enfant enfant1, enfant2; a.AjouterObjet("enfant", enfant1); enfant2 = a.RecupObjet("enfant"); enfant2.FonctionParent(); enfant2.FonctionEnfant();   return 0; }

---

Malheuresement, ce code ne fonctionne pas... :calim2:
J'ai essayer avec des template mais sans succés

Y aurait il donc un moyen de réaliser ceci ?
Aussi, est ce que ce genre de manipulation d'objet s'appellent le "downcasting" ?

Merci

Ça s'appelle du polymorphisme.
Le mot clé virtual va t'aider.
Je pense qu'un bon tuto sur les bases du C++ est nécessaire ;)

Au hasard, un exemple dans lequel on trouve quelques bonnes choses pour répondre à bcp de tes questions:
Runtime polymorphism demo

Oui c'est du polymorphisme je sais

Mais comment est-ce que rajouter virtual à chaque méthodes de la classe mère me permettrait-il de créer un conteneur stockant plusieurs objets de différentes classes héritant de la première.

Le polymorphisme et le typage dynamique nécessite l'utilisation de pointeur ou référence.

Donc je devrai plutôt faire ça ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

#include <map> #include <string>   class Parent { public: Parent(); void FonctionParent(); };   class Enfant : public Parent { public: Enfant(); void FonctionEnfant(); };   class structure { public: void AjouterObjet(std::string nom, Parent objet) { m_Objets[nom] = &objet; } Parent RecupObjet(std::string nom) { return *m_Objets[nom]; }   private: std::map < std::string, Parent*> m_Objets; };   int main() { structure a; Enfant enfant1, enfant2; a.AjouterObjet("enfant", enfant1); enfant2 = a.RecupObjet("enfant"); enfant2.FonctionParent(); enfant2.FonctionEnfant();   return 0; }

---

Il faudrait peut-être aussi changer les signatures de AjouterObjet() et RecupObjet() pour prendre des références ;)

Mais je pense que tu ne pourras jamais faire ce que tu veux dans ton main(). Le principe de stocker des Parents, c'est que ne sont pas des Enfants. Quand tu fais RecupObjet(), tu récupères un Parent, pas un Enfant. Ainsi, tu n'as pas accès aux méthodes définies dans la classe Enfant.

Ce code est une catastrophe... Désolé :roll:
Il faudrait lire, et sans doute aussi comprendre, les réponses qui te sont données.
Répondre ligne par ligne aux "défauts" de ton code reviendrait à te donner un cours complet.

En étant minimaliste:

• Oui, tu dois rajouter virtual à ta méthode void Parent::FonctionParent();
• Non, tu ne peux pas obtenir un conteneur stockant plusieurs objets de différentes classes héritant d'une classe de base.
  MAIS, comme le souligne Bousk, tu peux créer un conteneur stockant des pointeurs ou références vers des objets de classes différentes héritant d'une classe de base.

Citation:

---

Ce code est une catastrophe... Désolé

---

C'est pour cela que je suis ici à vous poser des questions

Pour le virtual, en effet j'ai oublié de le rajouter dans mon dernier commentaire malgré ta réponse

Citation:

---

MAIS, comme le souligne Bousk, tu peux créer un conteneur stockant des pointeurs ou références vers des objets de classes différentes héritant d'une classe de base.

---

Soit un conteneur comme celui-ci ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

#include <iostream> #include <vector>   using namespace std;   class Parent { public: Parent() {} void FonctionParent() { cout << "Parent" << endl; } };   class Enfant : public Parent { public: Enfant() {} void FonctionEnfant() { cout << "Enfant" << endl; } };   int main() { vector<Parent*> parents;   Enfant enfant1; parents.push_back(&enfant1);   return 0; }

---

Merci

Code:

---

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

class Parent { public: Parent() {} virtual void FonctionEnfant() { std::cout << "Parent" << std::endl; } };   class Enfant : public Parent { public: Enfant() {} void FonctionEnfant() { std::cout << "Enfant" << std::endl; } };   int main() { std::vector<std::unique_ptr<Parent>> parents;   auto enfant1 {std::make_unique<Enfant>()}; parents.push_back(std::move(enfant1)); parents[0]->FonctionEnfant();   return 0; }

---

Ce code ne compilera pas parce que FonctionEnfant n'existe pas dans Parent.
D'ailleurs faire du polymorphisme sans fonction virtual est... au mieux inutile.

Citation:

---

Envoyé par martantoine

Aussi, est ce que ce genre de manipulation d'objet s'appellent le "downcasting" ?

---

Je vais parler de cast car c'est un truc qui m'a fait un peu galérer au début de mon apprentissage.

Si tu as:

Code:

---

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

struct Parent {}; struct Enfant: Parent {};   [...]   // nos instances, que tu devra allouer dynamiquement si tu veux les mettre dans un container (dans un std::unique_ptr généralement) Parent parent; Enfant enfant;   // ici on simule ton problème, en perdant l'information sur le type Parent* a = &parent; Parent* b = &enfant;   // exemples de cast Enfant* c = static_cast<Enfant*>(b); // ok, on sait que b est un enfant, on a le droit de le cast Enfant* d = static_cast<Enfant*>(a); // ... pas bon, par contre aucun moyen de savoir si le retour est valide ou non au runtime, va causer des problèmes (undefined behaviours) Enfant* e = dynamic_cast<Enfant*>(a); // mais avec le dynamic_cast tu auras moyen de savoir si le cast a écouché, ici e va valoir nullptr.

---

En bref: tu peux static_cast tes instances si tu connais leur type.
Il existe un pattern ou tu vas utiliser une enum et un attribut dans tes instances pour indiquer leur type, afin de pouvoir static_cast.
C'est utile si tu as peu de types différents, et utilisé seulement quand il y a besoin de hautes performances (static_cast ne coûte rien au runtime, mais t'auras le coût des conditions sur l'enum).

dynamic_cas tva en revanche se faire au runtime (il faut le rtti d'activé du coup).
Ce qui veut dire que tu pourras vérifier si le cast s'est bien passé, en regardant son retour, mais ça aura un coût qui peut vite devenir non négligeable selon la complexité de ton héritage et la fréquence d'utilisation.
A connaître, mais à utiliser avec parcimonie et en connaissance de cause.

Dans ton cas, si toutes les méthodes publiques de ton api peuvent être contenues dans ton parent, alors utilise du polymorphisme (virtual, override).
Si tu as besoin de quelque chose de plus complexe, regarde du côté du pattern visitor. C'est du double dispatching et ça permet de faire des choses très intéressantes.


Ps:
Dans ton premier code j'ai l'impression que tu veux tag avec des string tes instances.
Ne fait jamais ça. Comparer deux string est coûteux. A la limite utilise une enum, mais en C++ tu peux utiliser des templates et typeid pour faire ça automatiquement.
Mais encore une fois, a utiliser si tu comprend bien ce que tu fais sinon tu risques d'avoir des surprises.

Salut,

Le fait est que, à partir du moment où tu as été assez bête que pour perdre le type réel d'une donnée en la considérant comme étant du type de la classe de base, tu n'as pas d'autre choix que de... travailler avec cette donnée comme s'il s'agissait d'un élément du type de base.

Le transtypage -- qu'il soit à base de static_cast ou à base de dynamic_cast -- ne devrait JAMAIS être envisagé, car il brise purement et simplement l'un des principes de base qui est l'OCP (pour Open Close Principle ou principe "ouvert fermé") qui nous dit -- pour faire simple -- qu'un code doit toujours être ouvert aux évolutions mais fermé aux modifications.

Autrement dit: tu ne devrais jamais avoir à modifier un code existant qui a été validé (pour lequel tu as pu confirmer qu'il agissait correctement) pour pouvoir introduire une évolution au niveau de ton projet.

Or, si tu as une classe Enfant qui hérite de Parent, tu dois t'attendre à ce que -- tôt ou tard -- tu te retrouve à devoir rajouter une classe Entant2 (et sans doute dix autres classes du même acabit) qui hérite également de la classe Parent, et du coup, à devoir modifier l'ensemble des endroits de ton code où tu as utilisé le static_cast (resp dynamic_cast) pour pouvoir introduire l'évolution.

Le problème, c'est que tu en auras à tellement d'endroits dans ton code que tu as de très fortes chances d'en oublier un ou plusieurs de manière systématique, et que cela provoquera forcément des bugs, vu que les endroits que tu oublieras ne prendront forcément pas tous les cas dérivés possibles.

Cependant, la bonne nouvelle, c'est que chaque donnée qui "passe pour être" du type de base au travers d'une référence ou d'un pointeur sait parfaitement de quel type réel elle est effectivement, et que, si cette donnée décide de se transmettre à elle même à une fonction, elle le fera sous a forme de son type réel.

Il est donc possible de contourner tous ces problèmes en utilisant la technique dite du "double dispatch" dont le patron de conception visiteur est l'une des mises en oeuvre possible.

Imaginons que nous ayons trois classes dérivées de Parent (appelons les Fille1, Fille2 et Fille3). Nous pourrions avoir un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

class Parent{ public: /* les éléments qui font partie d'une hiérarchie de classes ont   * "sémantique d'entité" : ils ne sont ni copiables ni assignables   */ Parent() = default; Parent(Parent const & ) = delete; Parent & operator = (Parent const &) = delete; virtual ~Parent() = default; /* toutes les classes fille passeront pour être du type "parent"   * nous devons donc avoir une fonction commune au niveau   * de cette classe   */ virtual void appelSpeciale() const = 0; }; class Fille1 : public Parent{ public:   void appelSpeciale() const override; void specialFille1() const{ std::cout<<"Fille1::specialeFille1() appelée\n"; } }; class Fille2 : public Parent{ public: void appelSpeciale() const override; void specialFille2() const{ std::cout<<"Fille2::specialeFille2() appelée\n"; } }; class Fille3 : public Parent{ public: void appelSpeciale() const override; void specialFille3() const{ std::cout<<"Fille3::specialeFille3() appelée\n"; } }; void appelFille1(Fille1 const & f){ f.specialFille1(); }   void appelFille2(Fille2 const & f){ f.specialFille2(); } void appelFille3(Fille3 const & f){ f.specialFille3(); } void Fille1::appelSpeciale() const{ appelFille1(*this); } void Fille2::appelSpeciale() const{ appelFille2(*this); } void Fille3::appelSpeciale() const{ appelFille3(*this); } int main(){ std::vector<std::unique_ptr<Parent>> allItems; auto ptr1 = std::make_unique<Fille1>(); auto ptr2 = std::make_unique<Fille2>(); auto ptr3 = std::make_unique<Fille3>(); allItems.push_back(std::move(ptr1); allItems.push_back(std::move(ptr2); allItems.push_back(std::move(ptr3); for(auto const & it : allItems){ it.get()->appelSpeciale(); } return 0; }

---

qui donnerait un résultat proche de

Code:

---

1 2 3

Fille1::specialeFille1() appelée Fille2::specialeFille2() appelée Fille3::specialeFille3() appelée

---

Le double dispatch c'est la vie. Par contre il ne faut pas oublier que ça utilise deux appels virtuels, et dans certains cas ça peut devenir très coûteux (un appel virtuel n'est pas gratuit).

Donc dire que le transtypage ne devrait jamais être envisagé, ça dépend des cas j'imagine.
Dans une hiérarchie fermée comme un système de collision avec N shapes définies par exemple, pour le test de collision je me demande ce qui est le plus performant entre un double dispatch et un test a base d'enum.
Personnellement j'utilise le double dispatch dans ce cas, car je me suis pas pris la tête a faire des benchmarks, mais j'ai vu beaucoup d'entreprises faire la guerre aux appels virtuels (de souvenir ubisoft en parlaient dans une cppcon).
Si quelqu'un a des chiffres ça m’intéresse.

Citation:

---

Envoyé par onilink_

Le double dispatch c'est la vie. Par contre il ne faut pas oublier que ça utilise deux appels virtuels, et dans certains cas ça peut devenir très coûteux (un appel virtuel n'est pas gratuit).

---

Si tous tes visiteurs font partie d'une hiérarchie commune (ou peut s'en faut), effectivement, cela utilise deux appels virtuels.

Mais ca, tu n'est obligé d'y avoir recours que dans le cadre d'un langage qui ne supporte que le paradigme orienté objet, lorsque tu mets en place une implémentation "classique" du patron de conception visiteur.

Or, il se fait que C++ est multi-paradigme, et que les paradigmes impératif et générique s'intègrent parfaitement bien avec le paradigme orienté objet ;)

Si tu regarde attentivement le code que j'ai donné en exemple, tu remarquera que je ne fais qu'un appel virtuel, auquel je ne peux pas couper, mais que tout le reste se fait au travers de fonctions libres, qui ne pourront en aucun cas être virtuelles ;)

Tu as cependant tout à fait raison: un appel virtuel n'est pas gratuit, et il faut prendre ce cout en compte ;)

Citation:

---

Envoyé par onilink_

Donc dire que le transtypage ne devrait jamais être envisagé, ça dépend des cas j'imagine.

---

Il y aura toujours des cas "peau de banane", des cas extrêmes dans lesquels on pourra estimer qu'il est peut-être préférable de contrevenir au règles générales et où l'on donner le sens de "jamais sauf si" au mot jamais.

Il faut cependant bien avoir conscience du fait que la décision de contrevenir à l'un des principes fondamentaux de la programmation (l'OCP dans le cas présent) n'est pas gratuite non plus: on paye simplement les choses de manière différente. En l'occurrence, on paye les choses sous la forme d'une dette technique: il y aura toujours un risque énorme pour que, pour ajouter une nouvelle fonctionnalité à notre programme, nous devions trouver un "pis aller" qui permette de "contourner" le problème que l'on a généré en décidant de ne pas respecter les principes fondamentaux il y a peut-être des années de cela.

Et ce "pis aller" lui-même ne respectant pas les principes fondamentaux, il y a toujours un risque pour que nous devions -- dans six mois ou dans un an, ou plus -- trouver un autre pis aller pour arriver à contourner le problème, et ainsi de suite sur toute la durée du développement du projet.

Et tous ces pis aller seront systématiquement des nids à emmerdes : de vrais nids à bugs, et l'origine de pertes de temps incroyables en périodes de dev.

Tu vas donc décider de gagner quelques fréquences d'horloges en évitant un appel virtuel, mais tu risques de les payer au centuple et bien plus encore d'un autre coté.

Citation:

---

Envoyé par onilink_

Dans une hiérarchie fermée comme un système de collision avec N shapes définies par exemple, pour le test de collision je me demande ce qui est le plus performant entre un double dispatch et un test a base d'enum.

---

Si tu peux garantir

1. que ta hiérarchie de classes n'évoluera absolument jamais,
2. que cette dérogation restera exceptionnelle
3. que le fait d'éviter un appel virtuel aura un impact majeur sur les performances (parce que tu devrais faire plusieurs millions d'appels virtuels par secondes tout au long de l'exécution)

Alors, oui, cela peut valoir la peine de déroger aux principes, à condition de pouvoir justifier chacune de ces conditions.

Si tu as affaire à une hiérarchie de classes à laquelle tu rajoutera un élément tous les six mois (ou tous les ans, même), que cette dérogation devient la "manière de faire normale" à chaque fois que tu as été "assez bête" que pour perdre le type réel de ta donnée ou que cela te permet d'éviter un appel virtuel qui ne sera effectué que de manière sporadique, alors, tu te donnes à toi et à ton équipe beaucoup de mal pour rien.

Citation:

---

Envoyé par onilink_

Personnellement j'utilise le double dispatch dans ce cas, car je me suis pas pris la tête a faire des benchmarks, mais j'ai vu beaucoup d'entreprises faire la guerre aux appels virtuels (de souvenir ubisoft en parlaient dans une cppcon).
Si quelqu'un a des chiffres ça m’intéresse.

---

Les société comme UBISOFT ont carrément abandonné le paradigme orienté objet pour toute une séries d'aspects, préférant se tourner vers une approche de type ECS.

Et oui, l'approche du "tout virtuel" n'est clairement pas la meilleure approche possible. Nous pourrions sans aucun problème faire un parallèle entre les fonctions virtuelles (et le double dispatch) et les fonctions récursives: ce sont des techniques géniales, mais qui sont adaptées à des situations bien précises, qu'il faut éviter d'utiliser à tord et à travers.

Mais, à moins d'avoir de très bonnes raisons pour recourir au transtypage "sauvage", il est sans doute encore bien plus intéressant d'utiliser les appels virtuels, ne serait-ce que parce que cela te permet de "relier" ton code à ta conception, et que cela n'a pas de prix ;)

Merci pour les précisions :)

Effectivement prévoir sur le long terme est toujours la meilleure chose à faire.
J'ai eu pas mal de problèmes de ce type à mes débuts, surtout que je travaille en solo, on fait vite des erreurs comme ça sans avoir personne pour les pointer du doigt.

Disclaimer : le message présent n'est pas assez pédagogique pour s'adresser à martantoine (désolé). Il s'adresse surtout à koala01 et onilink_.

Le remplaçant du patron de conception visiteur, c'est std::variant, à savoir le type somme du C++17. En fait, le patron de conception visiteur du paradigme objet n'est, au fond, qu'une émulation très verbeuse des types sommes.

Contexte :
Quand un code connaît la classe de base, mais pas les classes dérivées, cela facilite l'ajout de classe dérivée en respectant le principe ouvert-fermé. Par contre, si on ajoute une fonction virtuelle pure dans la classe de base, alors on doit changer toutes les classes dérivées. On viole alors le principe ouvert-fermé.
Au contraire, quand on crée un type polymorphe X dont l'utilisateur connaît la liste exhaustive des types possibles (par exemple A, B et C) et peut faire une sorte de switch-case en fonction de tous les types possibles (A, B et C), on peut facilement ajouter une opération dont le comportement dépend du type (A, B ou C) en respectant le principe ouvert-fermé. Par contre, si on ajoute un type D dans la liste des types possibles de X, alors on doit changer toutes les sortes de switch-case sur X. On viole alors le principe ouvert-fermé.
Donc le choix entre ces deux approches dépend du contexte.

Le visiteur et std::variant visent tous les deux à la deuxième approche : le code qui utilise le type polymorphe connaît la liste exhaustive des types possibles. Contrairement au downcasting à coup de dynamic_cast, le visiteur et std::variant sont tous les deux sécurisés (si on les utilise correctement) : si le code appelant oublie de prendre en compte un des types possibles, on a une erreur de compilation.
Remarque : pour avoir cette sécurité, du côté du visiteur, il faut que les fonctions visit soient virtuelles pures. Du côté de std::variant, pour avoir la sécurité, il faut utiliser std::visit.

std::variant bat très largement le visiteur sur la concision :

• Créer un nouveau type somme est très rapide avec std::variant : on tape :
  
  Code:

  ---

  1 2 3

  using AorBorC = std::variant<A, B, C>; using AorBorCRef = std::variant<std::reference_wrapper<A>, std::reference_wrapper<B>, std::reference_wrapper<C>>; using AorBorCConstRef = std::variant<std::reference_wrapper<A const>, std::reference_wrapper<B const>, std::reference_wrapper<C const>>;

  ---

  et pouf, c'est fini.
  Par contre, avec le visiteur, il faut créer des classes AWrapper, BWrapper et CWrapper qui encapsulent A, B et C et dérivent d'une classe AorBorCBase, qui contient les fonctions virtuelles void accept(AorBorCVisitor& v) et void acceptConst(AorBorCConstVisitor& v) const. Comme c'est très lourd, on aura tendance à sacrifier le découplage en faisant dériver directement A, B et C de AorBorCBase et on aura tendance à laisser tomber AorBorCConstVisitor et la const-correctness qui va avec.
• Avec std::variant, émuler un switch-case est concis : on utilise std::visit et on s'appuie sur la concision des lambdas. Avec un visiteur, il faut se taper une nouvelle classe qui dérive du visiteur de base et subir la lourdeur qui l'accompagne (déclaration des variables membres, définition du constructeur pour sauvegarder les informations contextuelles dans les variables membres, etc.)
• Pour faire du double dispatch (par exemple, pour implémenter une collision entre deux objets de type polymorphe telle que l'effet de la collision dépend des deux types à la fois), avec std::visit et std::variant, c'est facile et concis. Gérer cela avec un visiteur, par contre, c'est hyper lourd et cela fait intervenir beaucoup d'indirections. Du coup, dans la pratique, lors de la conception, le visiteur ne sera même pas envisagé et la collision sera gérée directement avec des fonctions virtuelles dans la classe de base AorBorCBase, pas de manière découplée dans un code extérieur.

Le seul gros défaut de std::variant par rapport au visiteur de la programmation orientée objet, c'est que std::visit nécessite certains prérequis en C++ (generic lambda, if constexpr et <type_traits>) pour pouvoir être utilisé de manière efficace et concise.
Remarque : Il existe d'autres langages dans lesquels les types sommes ne nécessitent pas de tels prérequis pour être manipulés de manière concise. Dans de tels langages, le patron de conception visiteur ne sert vraiment à rien.

Edit 2018-06-08-23h59 : ajout d'un point pour contourner un bogue d'affichage du message (deux paragraphes fusionnés en un).
Edit 2018-06-09-00h12 : amélioration d'une formulation.
Edit 2018-06-10-13h41 : ajout des versions avec std::reference_wrapper. C'était un oubli important.

J'avais déjà entendu parler de std::variant mais j'étais a mille lieux d'imaginer qu'on pouvait l'utiliser de cette façon.
Merci pour l'explication, c'est très instructifs, j'essayerais de jouer un peu avec, même si pour l'instant je suis bloqué sur c++11 (mais je ne me plains pas trop, ça aurait pu être pire :mouarf: ).