Vector et héritage

Version imprimable

04/02/2016, 15h33
grunk

Vector et héritage
Bonjour à tous,

J'ai un ensemble de classe qui héritent les une des autres :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Class Mere { public: Mere(); virtual ~Mere(); void MethodeDeMere(); } Class Fille : public Mere() { public: Fille(); ~Fille(); void MethodeDeFille(); }
Les différentes instances de Mereet Fillesont stockées dans un vecteur déclaré comme cela :

Code:

std::vector<Mere * > datas;

Tout celà marche bien.

Mon problème intervient quand j'ai besoin de récupérer les données.

Comment lors de l'itération du vecteur savoir quel est le type réel de l'objet lu afin de pouvoir récupérer les données qui lui sont propre ?
Je recherche à faire quelque chose comme ça :
Code:

1 2 3 4 5 6 for ( auto &d : datas ) { if(d == Fille) d->MethodeDeFille(); else d->MethodeDeMere(); }
Tester via un dynamic cast :

Code:

if(Fille* v = dynamic_cast<Fille*>(ptr))

ne me parait pas possible puisque 2 classe soeurs pourraientt valider le test (Fille 2 pourrait être casté en Fille par exemple). Sans compter qu'un dynamic_cast n'est certainement pas annodin en terme de performance.

Quelles sont mes options ?

merci

Hello,

Une simple méthode virtuelle ?

Code:

1
2
3
4
5
6
7
8
9
10
struct Mere {
   virtual ~Mere() { }
   virtual void foo() const { std::cout << "Mere\n"; }
};
struct Fille: Mere {
   virtual void foo() const { std::cout << "Fille\n"; }
};
 
Mere *m = new Fille;
m->foo(); // affiche "Fille"

04/02/2016, 15h50
grunk

Salut,

j'ai bien des méthodes virtuelles dans ma classe mère , mais là je suis dans le cas ou ma classe fille à une méthode qui lui est propre et qui n'a pas à être implémenter dans la classe mère (l'attribut qui lui est lié n'existe pas dans la classe mère).
04/02/2016, 16h14
ternel

Ca veut dire que tu sais déjà que tu as des filles.
Donc que tu es dans un vecteur de (pointeurs sur des) filles, et tu n'as pas de soucis.

Pourquoi voudrais-tu manipuler des Mères commes des filles. Il y en a qui n'en sont pas du tout.
04/02/2016, 16h16
grunk

Citation:

Envoyé par leternel

Ca veut dire que tu sais déjà que tu as des filles.
Donc que tu es dans un vecteur de (pointeurs sur des) filles, et tu n'as pas de soucis.

Mon vecteur contient des mères ET des filles. Au moment où j'itère sur le vecteur je ne sais pas si mon pointeur est une mère ou une fille , c'est ca que j'ai besoin de savoir.

Citation:

Pourquoi voudrais-tu manipuler des Mères commes des filles. Il y en a qui n'en sont pas du tout.

je veux manipuler les mères comme des mère et les filles comme des filles , puisque les filles implémentes des infos supplémentaires au mère
04/02/2016, 16h27
Iradrille

Citation:

Envoyé par grunk

Mon vecteur contient des mères ET des filles. Au moment où j'itère sur le vecteur je ne sais pas si mon pointeur est une mère ou une fille , c'est ca que j'ai besoin de savoir.

Garde 2 vecteurs.
04/02/2016, 16h28
grunk

C'est pas vraiment une option j'ai X classe dérivée , je vais pas créer un vecteur à chaque fois :/
04/02/2016, 16h29
ternel

C'est le role des fonctions virtuelles.
Si tu ne veux pas recourir à une fonction virtuelle, c'est qu'il y a un problème de conception.
Ca peut venir de ce que tu as perdu l'information de typage (normal, c'est un vecteur de pointeur de mere).
Ca peut venir de ce que tu aggreges des choses qui n'aurait pas du être ensemble, il te faut peut-être une collection de pointeurs de filles (et une pour les meres non filles)

Une fonction virtuelle ne signifie pas que c'est la fille qui défini la fonction, mais que celle-ci peut la redéfinir.
04/02/2016, 16h37
grunk

Citation:

C'est le role des fonctions virtuelles.
Si tu ne veux pas recourir à une fonction virtuelle, c'est qu'il y a un problème de conception.

Prenons l'exemple d'une classe "Vehicule" dont hérite Voiture et Avion. En quoi est ce une erreur de conception d'avoir une methode "GetEnvergure()" dans Avion et pas dans Voiture ?
Il faut impérativement que je déclare GetEnvergure() comme virtuelle dans ma classe Véhicule même si une seule classe parmis X fille va l'utiliser ?

--- Edit ---

J'ai trouvé une solution qui consiste à implémenter une fonction GetClassType() dans la mère qui retourne un attribute mClassType. Dans les class fille je redéfini mClassType à la valeur adéquate.
Du coup quand j'itère j'appelle GetClassType() et cast en fonction du resultat.
C'est pas très joli mais ca fonctionne en attendant mieux.
04/02/2016, 16h44
ternel

Non, mais pourquoi voudrais-tu connaitre l'envergure (en tant qu'avion) de chaque véhicule d'un ensemble dont tu sais pertinament qu'il contient probablement des voitures et des bateaux, en plus d'avions?
04/02/2016, 16h52
grunk

J'ai l'impression qu'on se comprend pas :mrgreen:

J'ai un vecteur avec un ensemble de véhicules.
Quand j'itère sur ces véhicules , je veux en connaitre l'envergure quand c'est un avion , la taille de l'helice quand c'est un bateau , etc ...
Le tout sans avoir à implémenter des fonctions virtuelles qui n'ont pas lieu d'exister pour tous .

J'ai trouver un semblant de solution (voir mon message précédent) , mais j'espérais qu'il y'ai une façon plus élégante d'y arriver, un peu à l'image de ce qu'on fait en JAVA avec instanceof() :

Citation:

Envoyé par grunk

J'ai l'impression qu'on se comprend pas :mrgreen:

J'ai un vecteur avec un ensemble de véhicules.
Quand j'itère sur ces véhicules , je veux en connaitre l'envergure quand c'est un avion , la taille de l'helice quand c'est un bateau , etc ...
Le tout sans avoir à implémenter des fonctions virtuelles qui n'ont pas lieu d'exister pour tous .

J'ai trouver un semblant de solution (voir mon message précédent) , mais j'espérais qu'il y'ai une façon plus élégante d'y arriver, un peu à l'image de ce qu'on fait en JAVA avec instanceof() :

Double dispatch peut être ?
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 struct Fille1; struct Fille2; void foo(Fille1 const& f); void foo(Fille2 const& f); struct Mere { virtual ~Mere() { } virtual void doSomething() const = 0; }; struct Fille1: Mere { void doSomething() const { foo(*this); } std::string tailleDeLaBarbeDuCapitaine() const { return "rouge"; } }; struct Fille2: Mere { void doSomething() const { foo(*this); } int truc() const{ return 0; } }; // traitements des Fille1 void foo(Fille1 const& f) { std::cout << f.tailleDeLaBarbeDuCapitaine(); } // traitements des Fille2 void foo(Fille2 const& f) { std::cout << f.truc(); } std::vector<Mere*> ms; for(auto f: ms) { f->doSomething(); }

04/02/2016, 17h34
dalfab

Citation:

Envoyé par grunk

Tester via un dynamic cast :

Code:

if(Fille* v = dynamic_cast<Fille*>(ptr))

ne me parait pas possible puisque 2 classe soeurs pourraientt valider le test (Fille 2 pourrait être casté en Fille par exemple). Sans compter qu'un dynamic_cast n'est certainement pas annodin en terme de performance.

Le dynamic_cast<>() n'est pas si couteux que cela (il est plus rapide que le InstanceOf), et ne nécessite qu'une seule instruction pour les hierachies simples.
Si l'on prend deux classes soeurs, en aucun cas le dynamic_cast<>() ne sera valide pour les deux (le cast vers un pointeur n'est valide que pour la classe elle-même ou une des classes descendantes, ne pas confondre avec le cast d'un type vers un autre qui ne peut pas être un dynamic_cast<>().

Le dynamic_cast<>() est donc possible et pratique, mais il signale très certainement un découpage mal pensé.
En C++, il ne doit normalement pas y avoir de cast. Mais l'équivalent du InstanceOf() est bien le dynamic_cast<>().
04/02/2016, 17h55
jo_link_noir

@LIradrille: Le double dispatch prend en compte le type réel des arguments, ici, ce n'est rien de plus que du polymorphisme.

@grunk: Tu peux regarder le pattern visitor (ou boost::variant). Bien évidement, cela s'applique qu'avec un nombre de types connus à la compilation.

Mais bon, si tu as X types différents pour X traitements différents, alors il n'y a rien d'incohérent d'avoir X tableaux différents.
05/02/2016, 08h39
ternel

Réfléchis à ce que fait la fonction qui parcoure l'ensemble en demandant des choses hétéroclites.
Je ne suis pas capable de nommer (ou commenter) une boucle du type for(i: ensemble) switch(type_of(i))

Et pourquoi ne pas faire un truc à la Objective-C? :weird:

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
typedef enum e_TYPE /*: unsigned char*/ {
    TYPE_MOTHER = 0,
    TYPE_DAUGHTER
} TYPE;
 
 
class Mere {
public:
    Mere();
    virtual ~Mere();
 
    virtual TYPE get_type() const = 0;
};
 
 
TYPE Mere::get_type() const {
    return TYPE_MOTHER;
}
 
 
class Fille : public Mere {
public:
    Fille();
    virtual ~Fille();
 
    virtual TYPE get_type() const { return TYPE_DAUGHTER; }
 
    void fake() { std::cout << "Ok" << std::endl; }
};
 
 
// ...
 
    Mere* mere = list_meres[0];
 
    if (mere->get_type() == TYPE_DAUGHTER) {
        ((Fille*) mere)->fake();
    }

05/02/2016, 10h08
grunk

Citation:

Envoyé par foetus

Et pourquoi ne pas faire un truc à la Objective-C? :weird:

C'est ce que j'ai fait pour le moment.

J'ai également testé avec le dynamic_cast après le commentaire de @dalfab . C'est effectivement pas si coûteux que ça et plus souple que la méthode avec un getType.

Merci à tous pour vos réponses.
05/02/2016, 10h19
ternel

Si tu pars dans cette direction (ce qui n'est pas forcément le bon choix), regarde ce qu'est Boost::Variant et le concept de tagged union.

Salut,

Autant le dire, je n'ai pas lu toute la discussion, mais, de manière générale ...

si tu décide de stocker des classes dérivées dans un conteneur (ici, c'est un std::vector, mais on pourrait choisir n'importe quelle autre collection ;) ) de classe de base, tu as deux solutions :

Ou bien tu te rends compte que tu as été "assez bête" pour perdre le type réel de tes objets, mais que cela ne change en définitive rien : tu manipules de toutes façons toutes les instances de classes dérivées exactement comme si tu manipulait des instances de la classe de base

Ou bien tu te rends compte que tu dois connaitre, à certains moments, le type réel de l'instance avec laquelle tu travailles, parce que l'on est tous bien d'accord sur le fait qu'il n'y a aucune raison de permettre à l'utilisateur d'une classe Voiture de lui demander son envergure!

Tu l'auras compris, la première situation est on ne peut plus simple : on se contente d'invoquer les fonctions propres à la classe de base, mais, la deuxième va rapidement devenir un vrai cauchemar. Car le problème, c'est qu'il existe un principe nommé OCP (pour Open Close Principle ou, si tu préfères en français le "principe ouvert / fermé") qui nous dit que, une fois qu'un comportement a été validé, nous de devrions plus avoir à le modifier pour pouvoir intégrer une nouvelle fonctionnalité.

Or, si tu commence à écrire un code qui pourrait prendre une forme proche de
Code:

1 2 3 4 5 6 7 8 /* soit ptrv est un pointeur sur un objet de type "véhicule" */ if(ptrv->isCar() ){ /* on fait quelque chose avec la voiture */ } else if(ptrv->isPlane() ){ /* on fait quelque chose avec l'avion */ } else if (ptrv->isMotorBike() ){ /* on fait quelque chose avec la moto */ }
tu vas rapidement te trouver dans une situation dans laquelle, chaque fois que tu voudras rajouter un "nouveau type de véhicule" (Ship, Submarine, Truck, SkateBoard, ...), tu devras trouver tous les endroits où ta logique est basée sur ce genre de tests pour... rajouter le nouveau type de véhicule. Et tu peux être sur d'une chose à cause de la loi de Finagle : tu oublieras systématiquement un endroit ou un autre.

Pour respecter l'OCP, il faut passer par une solution à base de "double dispatch" : En effet, chaque objet pointé sait exactement quel est son type réel, si bien que l'on peut demander à l'objet... d'appeler une fonction qui prenne, comme paramètre une référence (ou un pointeur) sur... le type réel en se donnant lui-même comme paramètre.

De cette manière, la fonction appelée saura qu'elle manipule une voiture et non un avion (par exemple, bien sur... à moins que ce ne soit le contraire :question:) ;)

Ce principe a d'ailleurs été reconnu par le GoF qui en ont fait un patron de conception connu sous le terme de Visiteur. Cependant, tel que présenté, le patron de conception visiteur n'est réellement utile que lorsque l'on dispose dés le départ d'une liste "relativement restreinte" et à peu près complète des types dérivés qui seront utilisés. C'est à cause de cette "restriction" que je n'ai pas voulu en parler dans un premier temps, mais tu peux (tu devrais) essayer de t'inspirer de ce patron de conception ;)