-
définition de conteneur
bonjours,
je veux definir un nouveau conteneur qui supporte un type générique c.a.d
Code:
conteneur<véhicule> cont;
dans la mesure ou je peux faire
Code:
cont.insert(¶m);
là ou param peut etre une classe dérivée de véhicule.
merci!!!!!!!!!!!!!!
-
Bonjour,
Tu pourras trouver des informations dans la FAQ :
1/Sur les conteneurs de la STL ;
2/Sur les template ;
3/Et sur l'héritage.
Je t'invite aussi à consulter les tutoriels pour te familiariser avec le C++.
-
bon
je reformalise mon but:
je voudrai definir un conteneur qui peut contenir un type de classe et les types dérivés de cette classe et ensuite acceder aux methodes de chaque classe.
le problème que j'ai rencontré avec les conteneurs est:
si je défini
Code:
vector <nom_classe_de_base*> myvector;
et ainsi si j"essaye de faire un push_back d'un element de type classe dérivée il va pas ce passer!!!
tu voire avec moi maintenat le pb.
merci d'avance
-
Les conteneurs classiques type std::vector fonctionnent très bien en général et par rapport à ton problème aussi. As-tu consulter la documentation les concernant ?
A titre d'information, si tu refais ton propre conteneur (à moins que ce soit dans un but d'apprentissage), tu as de grande chance de faire quelque chose de plus bancale. Il n'est pas recommandé de réinventer la roue.
-
Sujet traité cent fois.
Plusieurs solutions :
std::vector< std::unique_ptr<nom_classe_de_base> >
std::vector< clone_ptr<nom_classe_de_base> >
std::vector< std::shared_ptr<nom_classe_de_base> >
boost::ptr_vector<nom_classe_de_base>
std::vector< boost::varianet<nom_classe_de_base, nom_classe_derivee1, ..., nom_classe_deriveen> >
et encore plein d'autres.
En tous cas, std::vector<nom_classe_de_base*> est en effet la pire solution qu'il y ait, bien qu'elle soit beaucoup utilisée.
-
Salut,
Le problème, c'est que si tu décide, à un moment donné, de faire passer un objet de type dérivé pour un objet du type de base, il n'y a rien à faire, tant que tu ne précise pas que c'est en réalité bel et bien un objet du type dérivé, tu ne pourra accéder qu'aux méthodes définies dans le type de base...
Maintenant, ce que tu peux envisager de faire, surcharger une fonction dont la seule différence au niveau de la surcharge intervient sur le type dérivé pris en argument, de telle manière à être sur, dans chaque version de la fonction, du type réel manipulé et donc... d'être en mesure d'appeler l'ensemble des fonctions qui le composent...
Une autre solution pourrait passer par un design pattern "chain of responsability"