Discussion :

[julien_ma]

Bonjour à tous,

Quand je crée un pointeur de type classe A (classe mère),
devant pointer sur une sous-sous-classe (classe D),
celle-ci dérivant de deux sous-classes (classe B et classe C) de la classe A (classe mère),
le compilateur me dit : "classe A is a an ambiguous base
of classe D".

A *ptr = new D; // erreur

Ce problème est dû à l'héritage multiple car en héritage simple il n'y a aucun soucis,
je pense que le compilateur est perdu
à cause des deux sous-classes (classe B, C) parentes de la classe D.

Mais comment faire pour résoudre ce problème svp?

[Daïmanu]

Bonjour.

Ce que tu décris s'appelle l'héritage en diamant et se résout avec l'héritage virtuel (voir la FAQ).

[julien_ma]

Effectivement j'avais fait hérité virtuellement mes deux sous classes (B, C) de la classe A
pour éviter que lorsque l'on tente d'accéder à une donnée membre de la sous-sous-classe D,
déclarée dans la classe A l'on est pas de soucis du type quelle est la classe intermédiaire(B ou C)
qui va transmettre cette donnée membre dont elle a également héritée, malheureusement cela
ne résoud pas mon problème de pointeur.

[Invité]

Bonjour,

Et si tu nous montrais ce que tu as fait ?

Tu devrais vraisemblablement avoir quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class A { /* ... */ };
class B : virtual public A { /* ... */ };
class C : virtual public A { /* ... */ };
class D : public B, public C { /* ... */ };

[julien_ma]

Bonjour,

Voici mon projet ci-dessous, avec une image de l'erreur observée
(ps : dsl si le code peut un peu sembler confus, je n'ai pas respecter
le principe d'implémentation de la méthode dans le fichier cpp mais
l'ai fait directement dans le .hpp)

[Daïmanu]

Bonjour.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
class Cheval : public Animal
class Oiseau : public Animal

Tu ne fais pas l'héritage virtuel comme on te l'a montré, tes héritages devraient ressembler à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
class Cheval : virtual public Animal
class Oiseau : virtual public Animal

et ça devrait marcher beaucoup mieux

[julien_ma]

Merci à tous, effectivement j'avais fait hérité virtuellement dans ma tête cette héritage virtuel et non concrètement.

[TropMDR]

Fondamentalement, la vraie réponse a cette question est: ne fais jamais ça! L'heritage multiple en C++ est totalement incomprehensible et ne devrait jamais etre utilisé, a l'exception de l'implementation d'interfaces (en gros toutes les classes meres sauf une sont des interfaces pures)

[JolyLoic]

Fondamentalement, la vraie réponse a cette question est: ne fais jamais ça! L'heritage multiple en C++ est totalement incomprehensible et ne devrait jamais etre utilisé, a l'exception de l'implementation d'interfaces (en gros toutes les classes meres sauf une sont des interfaces pures)

Je ne peux qu'être en désaccord avec cet avis (mon désaccord étant plus ou moins important selon ce qui est entendu par "interface pure"). Je détaille mon point de vue dans http://loic-joly.developpez.com/arti...tage-multiple/

[Médinoc]

En fait, le gros point "gênant" sur l'héritage multiple, ce sont les variables d'instance.

De ce côté-là, tant qu'il n'y a pas de conflit de nom sur les fonctions membres, il n'y a pas vraiment de différence entre Non-Virtual Interface et interface "pure".

[Bousk]

http://loic-joly.developpez.com/arti...tage-multiple/

Je ne retrouve plus la discussion qui m'intéressait, mais ce post résume bien selon moi : l'héritage mutiple d'interface seule entraîne une duplication de code, qui aurait pu/du être factorisé dans la classe héritée.

[Médinoc]

Oui, j'ai vu partout des gens qui aimeraient bien un sucre syntaxique pour dire "rediriger les appels de cette interface vers cet objet qui l'implémente" (avec ou sans possibilité de redéfinir certaines fonctions).

Personnellement, je n'ai vu ce genre de fonctionnement concrètement que dans COM, qui appelle ce mécanisme "agrégation".

[koala01]

Salut,

Fondamentalement, la vraie réponse a cette question est: ne fais jamais ça! L'heritage multiple en C++ est totalement incomprehensible et ne devrait jamais etre utilisé, a l'exception de l'implementation d'interfaces (en gros toutes les classes meres sauf une sont des interfaces pures)

Tout à fait faux!!!

Ce qui se passe surtout, c'est que l'héritage public est la relation la plus forte qui puisse exister entre deux classes. Cela implique que c'est la relation à laquelle il faut apporter le plus d'attention avant de prendre la décision de la créer : l'héritage public apporte ce que l'on appelle la substituabilité, prérequis indispensable au polymorphisme par inclusion. Il faut donc s'assurer que le LSP (Liskov Substitution Principle ou principe de substitution de Liskov) est strictement respecté.

Evidemment, s'il faut déjà porter la plus grande attention à l'héritage simple, tu l'auras compris : il faut apporter encore plus d'attention à l'héritage multiple : Il faut déjà que la décision de faire hériter ta classe dérivée de chaque classe mère séparément soit particulièrement justifiée, mais il faut aussi que la décision de faire hériter ta classe dérivée de toutes les classes de base dans leur ensemble puisse être justifiée avec la plus grande rigueur.

Au final, on peut dire que l'héritage multiple est particulièrement complexe, personne ne le contredira. Mais il peut également s'avérer particulièrement intéressant pour autant que LSP soit strictement respecté.

Lorsque l'on est confronté à l'héritage en diamant, c'est souvent le symptome d'un problème de conception : soit parce que l'on a tendance à en demander trop à la classe "ancêtre", avec comme cause essentielle le non respect du SRP (Single Responsability Principle ou principe de la responsabilité unique)et de l'ISP (Inteface Segregation Principle ou principe de ségrégation des interface) et de la transformer en "god object", soit pour cause de non mise en oeuvre de pratiques et de patrons de conceptions éprouvés.

Il n'est pas forcément toujours possible d'éviter l'héritage en diamant, mais, si l'on amende un tout petit peu la notion d'interface telle que Java ou C# nous la vendent afin de permettre (après tout, il n'y a pas de raison de l'empêcher ) l'implémentation de certaines de leurs fonctions membres, il malgré tout souvent possible de l'éviter.

Ainsi, tu pourrais très bien envisager de créer une interface IB et une interface IC qui n'héritent absolument pas de A, et de faire en sorte que B hérite de A et de IB et que C hérite de A et de IC. D pourrait alors hériter de A, de IB et de IC, ce qui prendrait une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
/* classe de base de la hiérarchie principale */
class A{
    /* ... */
};
/* Interface spécifique à la classe B */
class IB{
    /* ... */
};
 
/* Interface spécifique à la classe C */
class IC{
    /* ... */
};
/* La classe B est un objet de type A qui fournit les services de IB */
class B : public A, public IB{
    /* ...*/
};
/* La classe C est un objet de type A qui fournit les services de IC */
class C : public A, public IC{
    /* ...*/
};
/* Et la classe D est un objet de type A qui fournit les services de IB et de IC */
class D : public A, public IB, public IC{
    /* ...*/
}

En rajoutant un peu de double dispatch (hein ? qui a parlé du patron de conception "visiteur" ), tu peux arriver à quelque chose de particulièrement correct et de bien plus évolutif que ce que tu ne pourrait avoir avec l'héritage en diamant

Evidemment, cela implique qu'il faudra réfléchir très sérieusement à ce qui se trouve dans IB et dans IC