héritage multiple et C++

Bonjour,
Pour les habitués de programmation en C++, voila une affirmation pour laquelle j'aimerais avoir vos critiques:

On sait que l'héritage multiple est autorisé en C++. Il y a donc un risque important de "losange de la mort".
Voila mon affirmation :
Il est conseillé aux programmeur de faire appel aux classes abstraites sans implémentation (classes virtuelles purs) en cas d'héritage multiple en C++. Les priver des champs (sauf pour les constantes) permet de minimiser davantage les risques de conflit.

C'est l'équivalent d'interface en JAVA.

Et c'est pour ça qu'on a créer l'héritage virtuel ...

J'en conclus que ma citation est correct?
Merci

J'ai jamais dis ça. J'ai dis que le langage nous fourni un moyen de répondre à la problématique que tu poses (héritage en losange) par le biais de l'héritage virtuel.

Commençons par comprendre le LSP, et l'héritage multiple passera mieux...

De plus, Les classes abstraites pures ne sont pas toujours la panacée, cf le pattern NVI et son application directe à la programmation par contrat.

PS: "classe virtuelle" n'existe pas. Une classe de base peut être virtuelle relativement à un héritage. Une classe peut ne disposer que de fonction membre virtuelles pures (et c'est autre chose).

Merci pour ces réponses.
Visiblement le C++ ne s'est pas contenté d'un équivalent d' utilisation d'interface de JAVA pour résoudre le problème du losange. Je vais me pencher dans l'application de l'héritage virtuel et surtout comment il est bâti.
En tout cas merci de m'avoir remis au bon chemin.

Citation:

---

et surtout comment il est bâti.

---

Hu? C'est un détail d'implémentation du langage ça ...

ah voilà je le trouvais plus, y'a un item dans la faq :
http://cpp.developpez.com/faq/cpp/?p...RITAGE_virtuel

Citation:

---

Envoyé par wafiwafi

C++ ne s'est pas contenté d'un équivalent d' utilisation d'interface de JAVA.

---

non, heureusement !

oh, il y a de beaux diagrammes UML dans la FAQ ;)

Merci à tous pour vos pertinentes réponses.

Citation:

---

oh, il y a de beaux diagrammes UML dans la FAQ

---

Y a -t- il un lien à me fournir; ça serait pas mal.

IL y en a un dans la réponse de Goten : héritage virtual

Ah, ok! Je l'avais déjà consulté et bien suivi.
Merci à toi

Salut,

Peut être serait il bon d'insister une fois de plus sur ce qu'a mis luc en avant, à savoir

Citation:

---

Envoyé par Luc Hermitte

Commençons par comprendre le LSP, et l'héritage multiple passera mieux...
<snip>

---

L'un des grands reproches que l'on puisse faire à java (par exemple), c'est de considérer que tout hérite implicitement d'un "super objet".

Quand on y regarde de plus près, le super objet (ou similaire) est le principal problème qui risque de provoquer le fameux losange de la mort et représente quelque part une très grosse infraction à LSP (Liskov Substitution Principle).

En effet, LSP met en évidence l'importance qu'il y a à assurer la substituabilité d'un objet du type de base avec un objet du type dérivé lors de l'héritage: Lorsque tu envisage l'héritage public, tu dois pouvoir faire cohabiter n'importe quel objet dont le type se trouve dans la hiérarchie de classes que tu crée, y compris, les types qui dérivent des types qui dérivent (et ainsi de suite) de ton type de base.

Lorsque tu décide de te baser sur un super objet, ou, du moins, sur un type de base trop générique, tu en arrive, selon Liskov, à admettre de faire cohabiter des voitures, des clients et des chiens (ou des poux) dans une seule et même collection d'objets.

Or, il semble évident qu'il te sera impossible de trouve le moindre service commun qui soit rendu par ces différents types :aie:.

A l'inverse, si tu n'envisage effectivement l'héritage public que pour les types pour lesquels la substituabilité est établie (un turbo compresseur héritant d'une turbine et d'un compresseur, ces deux derniers n'ayant aucun héritage commun, parce que ne rendant aucun service similaire :D), le risque de te retrouver face à un losange de la mort s'amenuise énormément :D

De plus, C++ fournit un autre paradigme des plus intéressants, qui te permet de contourner les risques résiduels: le paradigme générique.

L'idée est simple, mais, pour la développer, je vais schématiser (au moins sommairement) les trois paradigmes en présence:

Le premier paradigme qui a été mis en oeuvre (par C, par exemple) était le paradigme procédural: on s'inquiète, en priorité, au données que l'on doit traiter.

Avec la complexification des applications, un deuxième paradigme a été envisagé: le paradigme Orienté Objet.

On ne s'intéresse plus aux données en tant que telles, mais bien au services que l'on attend d'elles (en plus d'assurer la substituabilité, s'il échoit).

Le paradigme générique, enfin, s'intéresse moins au service que l'on attend des données à gérer qu'à... la manière dont les données sont gérées.

On remarque en effet que la manière dont une liste d'objet sera gérée sera identique que nous gérions une liste de petites cuillers, une liste de personnes, une liste de voitures, ou la liste des animaux d'un zoo.

En C++, le paradigme générique est mis en oeuvre grâce aux classes et aux fonction template.

Et, chose assez sympa, si on a une classe template MaClass, les spécialisations MaClass<int> et MaClass<UnTypeQuelconque> représentent, de fait, deux types tout à fait distincts, et permettent donc, lorsqu'elles interviennent dans un héritage, d'avoir une interface strictement identique mais... d'éviter le losange de la mort.

Au final, j'aurais presque tendance à dire que la crainte du losange de la mort, pour compréhensible qu'elle soit, est beaucoup plus induite par la méconnaissance (pour ne pas dire de l'ignorance délibérée) d'un principe de base que d'un problème réellement inévitable.

Alors, bien sur, il restera toujours, tout en utilisant l'ensemble des possibilités offertes (respect stricte de LSP et programmation générique) quelques exceptions qui feront que l'on peut malgré tout y être confronté un jour ou l'autre, et qui justifient, à elles seules, d'attirer l'attention sur le risque potentiel qu'il représente...

Pour ces exceptions, la réponse est simple: quand on est confronté, malgré tout le soin que l'on peut apporter à la situation, à la création d'un losange de la mort, il faut envisager... l'héritage virtuel :D

Citation:

---

Or, il semble évident qu'il te sera impossible de trouve le moindre service commun qui soit rendu par ces différents types .

---

Et bien moi, si.
Le fait qu'un objet est égale à un autre, sémantique variable en fonction du type d'objet.
Le type de l'objet pour utilisation de la réflexion.
Le fait de pouvoir le cloner, sémantique variable en fonction du type d'objet.
Le délesté de la mémoire s'il n'est plus utilisé.
...

bacelar, cela est trop artificiel et surtout trop ad hoc pour dire qu'il y à quelque chose d'intéressant de commun. Si on veut absolument que deux classes aient quelque chose en commun alors on trouvera toujours, mais cela ne veut pas dire que cela à un vrai sens.

personnellement cela fait pas mal d'années que je programme et ne me souviens pas avoir eu à subir un losange de la mort / héritage virtuel ;)

Citation:

---

Envoyé par bacelar

Et bien moi, si.
Le fait qu'un objet est égale à un autre, sémantique variable en fonction du type d'objet.
Le type de l'objet pour utilisation de la réflexion.
Le fait de pouvoir le cloner, sémantique variable en fonction du type d'objet.
Le délesté de la mémoire s'il n'est plus utilisé.
...

---

Mhhhh... Oui, mais non...

Demande toi surtout s'il te semble cohérent de permettre de faire cohabiter des objets de ces différents types dans une collection "unique" et l'usage que tu pourrais en faire...

Les services que tu présentes ici sont beaucoup trop... génériques pour que cela puisse avoir le moindre intérêt, parce que, si tu décide de permettre de les cloner, par exemple, ce sera pour mettre un patron "fabrique" en place.

Or, il ne me semble pas cohérent de demander à la même fabrique de nous renvoyer une fois un chien, une fois une voiture et une fois une petite cuiller :P

Tu pourrais, effectivement, envisager de créer une interface "IClonable" qui serait commune à tous ces types, mais cette interface ne devrait pas mettre en relation deux hiérarchies qui n'ont strictement rien à voir entre elles (la hiérarchie "animal" et la hiérarchie "véhicule").

Or, justement, la programmation générique, permet d'éviter de relier ces deux hiérarchies de classe:

Dans un code proche de

Code:

---

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

template <class T> class IClonable { public : T * clone() const{return new T(*this);} /*...*/ private: T(); T(T const &); }; class Animal : public IClonable<Animal> { /*...*/ }; class Vehicule : public IClonable<Vehicule> { /*...*/ }; /* suivent des types dérivant de Animal et / ou de Vehicule */

---

ne reliera absolument pas les deux hiérarchies :D

En outre, même si (je déconseillerai toujours de le faire :D) on venait à utiliser une class IClonable "classique" (non template), il y a peu de chances que tu finisse un jour par vouloir faire hériter un objet de Animal et de Vehicule (ou d'un des types dérivés): le char à boeufs, c'est un véhicule, mais le "à" indique bel et bien que les boeufs interviennent dans une aggrégation / composition et non dans un héritage :D

Citation:

---

Envoyé par bruno_pages

bacelar, cela est trop artificiel et surtout trop ad hoc pour dire qu'il y à quelque chose d'intéressant de commun. Si on veut absolument que deux classes aient quelque chose en commun alors on trouvera toujours, mais cela ne veut pas dire que cela à un vrai sens.

personnellement cela fait pas mal d'années que je programme et ne me souviens pas avoir eu à subir un losange de la mort / héritage virtuel ;)

---

Je suis tout à fait d'accord avec toi...

Bien souvent, le losange de la mort survient parce que l'on a pris, à la base, des décisions inadaptées et, d'une certaine manière, totalement contraires au LSP ;)

Citation:

---

Les services que tu présentes ici sont beaucoup trop... génériques pour que cela puisse avoir le moindre intérêt

---

C'est là tout l'intérêt, vu qu'ils s'appliquent à tous les objets.
Avoir une collection d'objet permet, par exemple l'implémentation d'un garbage collector, etc...

Citation:

---

Envoyé par bacelar

C'est là tout l'intérêt, vu qu'ils s'appliquent à tous les objets.
Avoir une collection d'objet permet, par exemple l'implémentation d'un garbage collector, etc...

---

Hou la la... Tu semble avoir raté le débat sur l'utilité d'un garbage collector en C++... ou être beaucoup trop imprégné de la mentalité java (cette dernière remarque ne doit être prise que pour ce qu'elle est: une boutade dite sans la moindre trace péjorative, hein :D).

En gros, on pourrait dire qu'il n'y a strictement aucun intérêt à envisager un garbage collector en C++ grâce à la flopée des pointeurs intelligents dont on dispose, soit au travers de la STL, soit grâce à boost :D

Cela ne règle pas les problèmes de localité, compactage mémoire, optimisation de parcours d'arborescence, adaptabilité transparente aux limitations de la plateforme pour des algorithmes de systèmes particulaires par exemple ...

Ne jamais se privé d'un outil simplement parce que l’on ne sait pas s'en servir.
Savoir sans servie, c'est aussi savoir quand il n'est pas utile.:ccool:

Citation:

---

Envoyé par bacelar

Cela ne règle pas les problèmes de localité, compactage mémoire, optimisation de parcours d'arborescence, adaptabilité transparente aux limitations de la plateforme pour des algorithmes de systèmes particulaires par exemple ...

---

Si ce n'est que tous ces problèmes trouvent une solution élégante en C++ qui ne nécessite aucunement le recours à un garbage collector :D

Citation:

---

Ne jamais se privé d'un outil simplement parce que l’on ne sait pas s'en servir.
Savoir sans servie, c'est aussi savoir quand il n'est pas utile.:ccool:

---

Le fait est, qu'en l'occurrence, un garbage collector n'est... absolument pas utile en C++...

Surtout au vu de la nouvelle norme :D

compactage mémoire + solution élégante en C++

Je demande à voir.

je me trompe ou cette discussion vire au troll ? :rouleau:

Citation:

---

Envoyé par koala01

Si ce n'est que tous ces problèmes trouvent une solution élégante en C++ qui ne nécessite aucunement le recours à un garbage collector :D
Le fait est, qu'en l'occurrence, un garbage collector n'est... absolument pas utile en C++...

---

Non pas tous. Typiquement la gestion de la fragmentation ne me semble pas avoir de solution élégante en C++ (si ce n'est de libérer dans un autre bien précis, et encore).

En outre ce n'est pas aussi évident que cela qu'un Garbage Collector soit inutile en C++[1]. A ma connaissance, la possibilité d'en intégrer un a été abordée et le point n'est pas tranché.

En outre il existe déjà des Garbage Collector en C++ de façon non standard.

Citation:

---

Envoyé par bacelar

Et bien moi, si.
[a] Le fait qu'un objet est égale à un autre, sémantique variable en fonction du type d'objet.
[b] Le type de l'objet pour utilisation de la réflexion.
[c] Le fait de pouvoir le cloner, sémantique variable en fonction du type d'objet.
[d] Le délesté de la mémoire s'il n'est plus utilisé.
...

---

Mais ce ne sont pas des "services communs" qu'offre les objets, seulement des "détails d'implémentation".

En outre:
[a] et [c] : justement je vois un problème à avoir ceci dans un super objet de base. Je ne souhaite pas nécessairement que tous mes objets soient duplicable ni comparable (cf sémantique de valeur/d'entité).
[b] et [d] : Juste quelques remarques:

• L'utilisation d'un super objet pour permettre la réflexion et la libération mémoire est un choix d'implémentation possible, pas forcément le seul.
• Ces deux caractèristiques n'ont rien en commun. Je ne vois pas pourquoi un même super objet aurait ces deux responsabilités.
• Enfin cela me semble être de l'héritage pour réutilisation de code, pas un hériotage au sens LSP du terme. Donc héritage privé et non public.

[1] A titre personnel, si cela ne remet pas en question les mécanismes existant et s'il est suffisament flexible, je ne suis pas du tout contre le fait d'avoir un garbage collector.

Sinon il y a déjà eu le débat sur le super objet, il était bien nourri et n'avait finalement pas été tranché, les deux camps du pour et du contre existants tout deux.

Citation:

---

je me trompe ou cette discussion vire au troll ?

---

Je ne pense pas. En tout cas grâce à vous j'ai appris plein de trucs. La tournure qu'a pris cette discussion est super importante puisque tout est lié! Ce qui m'a obligé de me projeter beaucoup plus loin dans la réflexion et surtout dans la documentation pour essayer de comprendre convenablement ce que chacun a avancé. C'est plutôt intéressant!
Je me rend compte que de l'écart du premier message que j'ai posté par rapport à la réalité et l'expérience de chacun. Tout cela est un catalyseur nous obligeant à lire, à nous documenter et surtout à bien réfléchir.
Bravo
Merci à vous

Peut être que ceci pourrait t'intéresser dans ta réflexion (c'est le cas de le dire :mrgreen:).

Citation:

---

Envoyé par bruno_pages

je me trompe ou cette discussion vire au troll ? :rouleau:

---

je dirais plutôt en quelque chose de stérile car basé exclusivement sur des "lieux communs" non justifiés...

Ceci dit, la remarque de wafiwafi est également correcte: la solution au problème de l'héritage en losange ne peut pas être résumée en deux phrases et justifie une réflexion en profondeur, surtout avec un langage aussi fourni que C++...

D'autres langages suivent d'autres philosophies et apportent (ou non) d'autres solutions à ce problème, mais cela fait partie des conséquences d'un choix fait à la base :D