Bof, je ne vois vraiment pas pourquoi...Citation:
Envoyé par icer
Version imprimable
Bof, je ne vois vraiment pas pourquoi...Citation:
Envoyé par icer
Tout simplement parceque ça n'est pas une bonne conception : surtout lorsqu'il y a des noms de membres communs dans les supers classes. Comment savoir quels membres vient de quelles classes.Citation:
Bof, je ne vois vraiment pas pourquoi...
Un exemple trés simple :
C'est la même chose pour les méthodes.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Je le répéte : une conception avec de l'héritage multiple n'est pas une conception saine.
Il y a un cas où l'héritage multiple peut-être judicieux : lorsqu'on effectue une conception avec des interfaces, comme en java... dans les autres cas c'est fortement déconseillé. (sauf si on veut s'arracher les cheveux :aie:)
Bonsoir,
Justement le compilateur n'autorise pas ça.Citation:
Envoyé par icer
On peut y parvenir si le membre est dans une classe de base commune.
J'utilise l'héritage multiple pour une interface GUI (avec SDL), et c'est tellement utile dans ce domaine que j'ai du mal à croire qu'il n'est pas utile autre part.Citation:
Envoyé par icer
Si ta bibliothéque de GUI est bien conçue, je peux te croire que c'est bien pratique. Le problème avec le c++ c'est qu'il ne différencit pas syntaxiquement un héritage d'une implémentation d'interface (ce que java fait). En c++ c'est au programmeur de faire la différence, donc à prendre plus de précaution avec l'héritage multiple, voir même l'éviter...Citation:
J'utilise l'héritage multiple pour une interface GUI (avec SDL), et c'est tellement utile dans ce domaine que j'ai du mal à croire qu'il n'est pas utile autre part.
J'ai eu à travailler pas mal ces derniers temps avec un langage qui permet l'héritage multiple d'interface, mais pas l'héritage multiple en général (C# en l'occurrence), et je peux te dire que le manque d'héritage multiple m'a conduit à écrire du code bien plus sale (avec duplication et tout) que si j'en avais eu.
Désolé de ne pouvoir décrire plus le problème ici (après tout, je ne suis pas proprio du code en question, et puis ça prendrait du temps à décrire). En particulier, j'aurais pu dans ce cas obtenir un résultat satisfaisant sans héritage multiple, mais il m'aurait fallu pour ça réorganiser les responsabilités autrement dans la hiérarchie de classes, et ça je ne pouvais pas le faire, car il s'agit de classes issues d'une bibliothèques externe. Avec l'héritage multiple, le problème était résolu en 2 lignes.
Je ne dis pas que l'héritage multiple (dans sa version complète) s'utilise tous les jours, dans toutes les hiérarchies de classes, mais je dis qu'il y a des cas où il est utile, et que dans ces cas, les alternatives sont beaucoup moins satisfaisantes.
Et je n'ai pas encore vu d'arguments qui expliqueraient en quoi l'héritage multiple serait problématique (à par que c'est plus difficile à implémenter, ce qu'en tant qu'utilisateur du langage, je n'ai rien à faire).
L'héritage multiple t'a permis de "rattraper" une mauvaise conception de la bibliothèque... c'est plus pour une raison pratique que pour une raison de conception.Citation:
... mais il m'aurait fallu pour ça réorganiser les responsabilités autrement dans la hiérarchie de classes...
Lors de la conception : on peut identifier exactement 4 types de relation entre classes :Citation:
Et je n'ai pas encore vu d'arguments qui expliqueraient en quoi l'héritage multiple serait problématique (à par que c'est plus difficile à implémenter, ce qu'en tant qu'utilisateur du langage, je n'ai rien à faire).
- IS A : est un
- HAS A : a un , est composé d'un
- USES A : utilise un, communique avec un ...
- BEHAVES AS A : se comporte en tant que
L'héritage est implémenté uniquement pour "IS A" et "BEHAVES AS A".
Et dans le cas de "BEHAVES AS A", il s'agit d'interface, qui en c++ est implémenté grâce à l'héritage multiple.
Elle n'était pas mauvaise en tant que telle. Elle n'était juste pas adaptée à mon besoin. Il n'est pas possible de faire un truc qui convienne à tout le monde. Mon besoin était de combiner deux aspects existants et indépendants d'une bibliothèque existante.Citation:
Envoyé par icer
Et je n'aurais pas pu le faire en refactorant la bibliothèque tout en la laissant indépendante de mon code : j'aurais pu le faire uniquement en introduisant des concepts spécifiques à mon code au sein de la bibliothèque. Ce qui n'est pas un bon design. En gros, J'avais A et B dans la bibliothèque, B dérivant de A. dans mon code, j'avais C, qui dérivait de A, et D, que j'aurais aimé faire dériver de C et B. La "solution" à héritage simple aurait consisté à avoir l'arborescence A<-C<-B<-D, mais du coup, il n'existait plus de class B générique et autonome dans la bibliothèque.
Voir par exemple http://archive.eiffel.com/doc/manual.../multiple.html pour d'autres arguments en faveur de l'héritage multiple, avec lesquels je suis assez d'accord.
Tant qu'on ne défini pas plus précisément ces termes, j'ai du mal à faire des discussions fines sur eux. Ma définition de IS-A est la suivante :Citation:
Envoyé par icer
B IS-A A ssi, dans chaque fonction qui a été conçue pour prendre en paramètre un objet de type A, on peut à la place passer un objet de type B, et obtenir un comportement correct.
Je n'ai pas de définition pour BEHAVES-AS.
J'attends tes définitions pour poursuivre la discussion.
Nous avons la même définition de IS-A.
En ce qui concerne BEHAVE-AS-A, il s'agit d'une relation avec la même propriété que tu as définis. Cependant, elle est moins forte.
Je vais prendre un exemple pour imager la chose:
Une relation IS-A : un Aigle est un Oiseau
Une autre relation IS-A : un Avion est un Véhicule
Ici nous avons deux classes, même si elle n'héritent pas de la même classe de base, elles sont toutes les deux un comportement en commun qui est voler().
On peut définir une interface se nommant "QuiVole" :P avec une méthode voler(), et sa relation avec les deux autres classes serait de type BEHAVES-AS-A :
Un Aigle se comporte comme un QuiVole
Un Avion se comporte comme un QuiVole
Le problème en C++ est que les interfaces n'existent pas syntaxiquement. Mais on peut les définir comme étant des classes abstraites, sans données membres et possédant uniquement des méthodes virtuelles pures.
Le programmeur qui implémente une telle conception doit faire la différence entre ces deux types de relations même si elle s'écrivent exactement de la même manière : un héritage.
En java, par exemple, la distinction est claire :
La même chose en C++Code:
2
3
Je soutiens l'idée que l'héritage multiple en C++ doit être utiliser uniquement dans le cas d'implémentations d'interfaces.Code:
2
3
Je soutiens pour ma part que la distinction entre extend et implement en Java (ou entre IS-A et BEHAVES-AS-A) est artificielle et n'existe que pour contourner un manque du langage : L'absence d'héritage multiple.
En outre, pour moi, une interface bien faite DOIT contenir du code : Le code de test qui valide les pré et post conditions de la fonction de l'interface, et qui ne DOIT pas varier selon la classe qui implémente l'interface. Une interface peut aussi contenir d'autre code, comme par exemple du code d'instrumentation.
Reprenons ton exemple, et définissons un peu plus l'interface QuiVole. Si je l'écris en Java (ne pas faire attention à la syntaxe, je ne connais pas Java, c'est pour l'idée) :
Code:
2
3
4
5
6
7
Et la version C++ (ne pas faire attention à la syntaxe, je connais le C++, mais je suis fainéant et c'est juste pour l'idée ;)) :
Quand on compare les deux versions, on se rend compte que la version "riche" de l'interface :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
- Sépare clairement les fonctions destinées à l'utilisateur de QuiVole de celles destinées à un implémenteur d'objet QuiVole, alors que ces deux aspects de l'interface sont mélangés en Java.
- Défini et valide un contrat sur l'altitude, que toutes les classes dérivées devront respecter.
- Evite les duplications de code qu'il y aurait
- soit dans toutes les classes dérivées entre altitudeEnM et altitudeEnPieds, la relation entre ces deux fonctions ne pouvant pas varier d'une classe dérivée à l'autre,
- soit dans le code utilisateur si on décidait de ne garder dans l'interface qu'une seule de ces deux fonctions.
Le dernier point n'est pas théorique : Dans mon code en C#, je retrouve assez régulièrement cet idiome : Deux classes implémentent la même interface, mais comme on n'a pas pu mettre de code au niveau de l'interface, et qu'on ne veut pas le dupliquer, on crée une autre classe dans laquelle on a une fonction statique qui reprend ce code (on lui passe les paramètres qui vont bien) et dans chacune des implémentations de l'interface, on duplique un appel vers cette fonction statique. C'est lourd, et ça n'apporte rien à la lisibilité, bien au contraire.
De ce que j'ai pu ressentir, les philosophies C++ et Java sont vraiment différentes sur ce point.
En Java, on parle d'une interface en terme de comportement/contrainte à gérer/respecter et de classe abstraite en terme de services à rendre.
Si vous connaissez le Smalltalk, pour vérifier que deux objets se comportent (BEHAVE-AS) de la même facon, on comparerait non pas leur type (ce qui comparerait IS), mais leur protocole (les messages auxquels ils répondent).
L'héritage n'est qu'une des solutions d'implémenter la notion de BEHAVE-AS-A. Autrement dit, le fait que deux classes qui se comportent pareil soient dans la même hiérarchie de classes en C++ n'est qu'un effet de bord du langage.
En Ruby par exemple ce n'est pas le cas. Le langage étant plus laxiste, on se contente de fixer quelques règles de nommage pour les méthodes.
Pour tester une relation IS, on utiliserait ainsi is_of?, et pour BEHAVE-AS on utiliserait respond_to?.
L'interface correspond donc à la notion de BEHAVE-AS-A en java: on veut assurer que d'une capacité à réagir à certaines demandes, dans un certain contexte.
On aura donc des Iterable : l'objet peut agir comme un conteneur séquentiel, des Displayable : l'objet peut agir comme quelquechose d'affichable, des Immutable : l'objet peut garantir sa non-modification, Comparable : ces objets peuvent être comparés, etc...
L'héritage utilisé ici n'a rien à voir avec celui utilisé dans le cadre d'une relation IS-A. C'est en fait très lié à ce qu'on apelle le "duck typing", plus répandu dans les langages dynamiques: "Je me fiche de ce que c'est réellement, tant que ca fait coincoin quand je lui demande, alors c'est un canard".
Pour s'en convaincre, il suffit de regarder le source d'une interface standard en Java, prenons Comparable. De tête, ca doit ressembler à quelquechose comme ca:
Comparable n'a qu'une seule vocation: placer une contrainte sur le nom de la fonction chargée de la comparaison.Code:
2
3
4
En java, on considère donc qu'un objet n'a qu'une seule nature portée par son héritage "extends", mais qu'il peut se comporter de multiples facons, porté par son héritage "implements".
Ce genre de distinction n'est pas habituel en C++. Je soupçonne que ce soit parceque le langage est beaucoup plus riche en mécanismes d'instauration de contraintes:
Pas besoin de Comparable en C++, il y a la surcharge d'opérateurs.
Pas besoin de Immutable en C++, il suffit de suffixer les méthodes par un const.
Etc..
Bon après, je ne suis pas spécialiste de java, je n'en fait qu'en cours, donc tout ce que je dis là, ce n'est que ce que j'ai pu ressentir de ce langage à travers mes ptits yeux de jeune programmeur C++ :)
SalutPersonnellement, je ne vois pas pourquoi il s'agirait d'une mauvaise conception...Citation:
Envoyé par icer
Après tout, la méthode UML autorise tout à fait d'y faire appel, et si on peut déconseiller dans certains d'y faire appel, c'est généralement pour la cause:
citation de mémoire tirée tout droit d'un bouquin bien coté sur le site sur la conception UML en java...Citation:
certains langages (java par exemple) ne l'autorisent pas... il faut donc pour ces langages faire le choix entre la pérennité de la conception en concevant de manière tout à fait indépendante du langage ou une conception adaptée plus adaptée au langage mais dont la pérennité est moins garantie
L'hértiage est à utiliser quand on peut peut sémantiquement parlant dire qu'un objet de la classe dérivée est un objet de la classe de base et que la suppression des caractéristiques de la classe de base rendent la classe dérivée non viable (comprendre "non viable comme" le fait qu'il commence à lui manquer des caractéristiques importantes)
Ainsi un chien est un mammifère, et si tu lui retire les caractéristiques qui en font un mammifère, ou qui en font un animal (car un mammifère est un animal), le type ne peut plus rendre les services de base.
De la même manière une voiture est un véhicule, et si tu retire les caractéristiques qui font le "véhicule", ton objet n'est plus en mesure de rendre les services de base.
Enfin, s'il est sémantiquement correct de considérer qu'un turbo-générateur est une turbine et que c'est un générateur - car il n'est pas possible de dire qu'il s'agit d'une turbine disposant d'un générateur ni l'inverse, et que les caractéristiques de l'un dépendent fortement des caractéristiques de l'autre - pourquoi ne pas utiliser l'héritage multiple avec une turbine et un générateur, alors que la méthode de conception ET le langage l'autorisent :question:
Bien sur, comme de nombreuses autres possibilités offertes en programmation, il s'agit d'être particulièrement prudent lorsque l'on décide d'avoir recours à l'héritage multiple...
Et ce d'autant plus si on en arrive à un arbre d'héritage dit "en losange", voir, "en diamant" (c'est à dire où les différentes classes qui servent pour l'héritage ont un ancêtre commun)
Il est, bien sur, possible d'éviter le recours à l'héritage multiple, mais si pour ce faire, il faut en arriver à multiplier le nombre de classes par deux ou à augmenter le temps de conception dans la même mesure, il est peut être utile de décider d'utiliser toutes les possibilités offertes par les méthodes de conception et par le langage ;)
Pour moi, un des intérêts principaux du duck typing, c'est de pouvoir aisément utiliser en tant que colvert et sans la modifier une classe qui ne connaissait pas la notion de colvert au moment où elle a été écrite, pour peu qu'elle ait été écrite en utilisant certaines conventions de nommage.Citation:
Envoyé par NewbiZ
Si la notion d'interface est du duck typing, alors c'est : "Je me fiche de ce que c'est réellement, tant que ca fait coincoin quand je lui demande, et que de toute façon, je sais dès le départ que c'est un canard, alors c'est un canard" :wink:
Si on devait rejeter l'héritage multiple parce que des gens ne savent pas s'en servir, alors on devrait rejeter l'héritage tout court parce que ces même gens ne savent pas s'en servir. Que de fois j'ai vu le LSP bafoué. Quand cette notion n'est pas comprise, qu'il y ait 50 ou 1 héritage ne change rien, le design est pourri et finira par nous coincer.
Sinon, comme Loïc j'ai également été élevé au James (si je puis dire ^^'), et l'héritage multiple de contrats est un énorme avantage offert par l'héritage multiple non bridé. Rien que pour cela, cette fonctionnalité n'est pas à bannir.
Pour ce qui est du IComparable, j'attribue la différence essentiellement à deux faits:
- Le Java ne supporte pas la sémantique de valeur aussi proprement (ou supporte pas tout court?) que le C++ ; chez lequel mélanger héritage et sémantique de valeur est suicidaire
- Le C++ a un typage plus précis, à la limite duck-typing, quand on veut écrire des TAD. L'arrivée des concepts rendra la chose plus propre.
Personnellement je ne me rappelle pas avoir eu besoin d'héritage multiple autrement que pour l'implémentation de multiples interfaces.
Ce qui me chagrine dans l'héritage multiple, c'est surtout que c'est pas performant, et se limiter aux interfaces ne résout aucunement le problème à ce que je sache.
Il m'est arrivé récemment une chose étrange, où l'héritage multiple m'a été très utile. C'est dans une application un peu complexe (un jeu), avec des classes assez abstraites, par exemple des classes qui se contente d'implémenter un algorithme, des classes qui représentent certains objets qui existent déjà, mais d'une autre manière afin d'améliorer les performances sur certains traitements, etc.
Et je me suis retrouvé dans un cas où j'avais besoin d'ajouter des fonctionnalités dans une classe (disons A), mais ces fonctionnalités existaient déjà dans une autre classe (disons B) qui n'avait cependant rien à voir. Ce que j'ai fait: j'ai sorti de B les fonctions dont j'avais besoin dans une nouvelle classe C, je l'ai aggrégé à B, et j'en ai fait hériter A. Du coup A hérite de 2 classe parce qu'elle héritait déjà d'une autre classe.
Au début je trouvais ça un peu risqué, brouillon. D'autant plus que j'aurais pu faire une aggregation, mais ça me plaisait moins car dans mon cas, l'héritage facilitait une implémentation qui assurait une gestion propre des ressources (RAII). Et puis finalement, au fur et à mesure des ajouts et de la maturation de cette application, je trouve que cet héritage multiple est fort pratique et finalement pas si dangereux que ça. Et maintenant je l'utilise ailleurs.
Par exemple pour l'affichage graphique: j'ai un objet qui hérite de la classe Displayable (classe qui contient les données et les fonctions nécessaires à l'affichage) et de Serializable (classe qui fournit les fonctions, les données et l'interface pour plusieurs types de sérialisations dont j'ai besoin dans ñom appli). Au final, je ne vois pas où est le danger.
Seulement il est vrai que dans mon cas, on s'approche de la programmation par interface, à ceci près que mes interfaces implémentent déjà des fonctionnalités.
performant dans quel sens ?Citation:
Envoyé par loufoque
Ben t'as un pointeur de vtable par classe héritée, l'upcasting nécessite de réaligner, etc.
quant a additionner un chiffre a un autre, je ne dis pas que c'est l'operation la plus rapide d'un cpu, mais bon. chipoter sur les cycles, ca va 5 minutes.Code:
2
Citation:
Envoyé par screetch
e pouvant a priori être non nul pour des contraintes d'alignement, plus d'autres chose que j'oublie peut-être.Code:sizeof C <= sizeof(A) + sizeof(B) + e
Mon < vient du cas suivant :
Maintenant, je suis d'accord pour dire que dans la plupart des domaines d'application, je ne pense pas que le surcout de l'héritage multiple soit sensible.Code:
2
3
4
5
6
7
je vais reformuler
merci pour la remarque =)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Pour ma part, c'est pour l'héritage multiple, cf les posts de Loïc, Luc et r0d pour les raisons.
Pour le surcoût, disons qu'il est très largement supportable, loufoque ;)
Citation:
Personnellement, je ne vois pas pourquoi il s'agirait d'une mauvaise conception...
Après tout, la méthode UML autorise tout à fait d'y faire appel, et si on peut déconseiller dans certains d'y faire appel, c'est généralement pour la cause:
UML n'est pas une méthode mais un language. Dire qu'on peut le faire car UML le permet c'est dire : on peut tout faire car on peut le dire.Citation:
il est peut être utile de décider d'utiliser toutes les possibilités offertes par les méthodes de conception et par le langage
1] Bon c'est un point de détail par rapport au débat, mais j'ai une petite question par rapport à ça : qu'en est-il de l'héritage d'implémentation ?Citation:
Envoyé par Luc Hermitte
Petit exemple, dans le cadre du boulot je devais implémenter deux types de courbes. La première, générale, est en gros un vecteur de point. Donc classe qui va bien avec méthodes qui vont bien (relativement nombreuses).
Le deuxième type représente une courbe pouvant être shiftée. Du point de vue concept c'est une courbe, mais qui offre des services supplémentaires. D'un point de vue utilisation, on ne l'utilisera jamais comme une courbe simple, en gros je n'aurais jamais quelque chose du style :
Avec faitUnTruc méthode non virtuelle et curve de type ShiftableCurve*. Mes courbes ne sont donc pas sensées être à sémantique d'entité. Et de mon point de vue une courbe shiftable est une courbe.Code:
2
Ca me paraît donc naturel de faire hériter ShiftableCurve de Curve plutôt que d'utiliser la composition et de rediriger toutes les méthodes communes non ?
2] Deuxième question, par rapport aux évocation de contrat faites par JolyLoïc. Ma référence étant le bouquin de Bertrand Meyer, lequel affirme qu'une fonction ne devrait pas tester sa précondition. De plus je me rappelle un message (de Luc Hermite ou Jean-Marc Bourguet, dsl je ne sais plus :)) affirmant que les exceptions n'étaient pas le mécanisme le plus approprié pour gérer les ruptures de contrat en C++.
D'où deux questions : est-ce que l'affirmation de Meyer (une fonction ne devrait jamais tester sa précondition) vient du fait que son langage (Eiffel) supporte nativement la programmation par contrat ? Et deuxièmement quel mécanisme préconisez-vous pour la gestion des ruptures de contrat en C++? Les assertions ?
Je n'ai pas lu le livre (et je le regrette), juste quelques extraits, donc je ne sais pas quels arguments il développe. Est-ce qu'il sépare le raisonnement pour les pré et les post conditions ici ? Mais d'un point de vue, c'est bien ce qui est fait par la méthode d'interface en C++, puisque les préconditions de la fonction virtuelle privée sont vérifiée par une autre fonction, non virtuelle.Citation:
Envoyé par bolhrak
Dans un monde parfait avec de bons tests unitaires, un mécanisme type assertions. Dans un monde bordélique, je sais pas trop.Citation:
Envoyé par bolhrak
Mais, à partir du moment où:Citation:
Envoyé par icer
- le langage de programmation permet quelque chose
- le langage de conception permet cette même chose
je ne vois de toutes manières aucune raison pour décider de se passer de cette possibilité sous prétexte qu'il "faut faire attention quand on l'utilise"...
Pour moi, aucune possibilité n'est mauvaise, même si on trouve pour certaines d'autres possibilités plus efficaces...
L'héritage multiple fait partie de ces possibilités pour lesquelles il est nécessaire de réfléchir à la différence entre la plus value qu'il fournit et les risques/problèmes qu'elles impliquent.
Si le bilan est globalement positif, que les circonstances sont clairement maîtrisées et correctement étudiées, pourquoi se refuser le recours à cette technique :question:
1] Chez moi "héritage d'implémentation" ne veut pas dire grand chose -- la faute au Java qui utilise ce terme pour différencier des choses bien moins essentielles que la dichotomie que je trouve primordiale -> Je me limite à un monde simple où il n'y a que deux héritages: un de substituabilité, et un de réutilisation de code. Et après, au feeling, je compose parfois.
La question N°1 est substituabilité ou pas. Si oui, héritage public.
S'il s'agit juste de réutiliser du code, il peut m'arriver d'utiliser l'héritage privé, mais ce n'est pas nécessaire. Tout dépend de comment est prévue la classe fournissant le service, de la quantité d'appels à déléguer sans traitements préalables, de si un couplage extrêmement fort est acceptable, etc...
2] Dans ma compréhension de la PpC de Meyer, les contrats servent à "surveiller" les erreurs de programmation. Pour cela, l'outil premier est l'assertion en C++. Je vois les Tests Unitaires comme un outil secondaire qui permet de vérifier que l'on a bien la sortie attendue dans un certain nombre de cas identifiés à la main. (il permet d'autre choses comme assurer de la non régression sur ces cas, ...)
Après, quand je parlais de contrats plus haut, j'avais une vision plus large où je vais étendre le contrat à des conditions d'applicabilité dynamique. Là je vais utiliser des exceptions. Par exemple dans la fonction d'interface d'une API, je vais renvoyer une exception si un fichier ne peut être lu, ou si son contenu est corrompu. En interne, je sais que ma couche d'interface m'assure le bon état du fichier, ou des données extraites. Là, je vais partir sur des assertions car si cela cloche ensuite, c'est que je me suis planté dans mon code, ou même dans mes suppositions quant à ce que je suis censé manipuler.
Pour en revenir à l'héritage multiple de contrats, la technique portée par James, peut être utilisée aussi bien pour les contrats à la Meyer (erreurs de codage/conception/...), que pour des contrats plus "dynamiques", liés au contexte d'exécution.
Est-ce au code client, est-ce au code métier de tester les contrats? Je n'ai pas de réponse à apporter aujourd'hui : je n'ai pas suffisamment creusé la question. Pour l'instant, mon approche est pragmatique, sur des modèles de codage similaires, je factorise le mécanisme de vérification à côté du code métier.
Demain je peux très bien changer d'avis.
Je m'attendais a te voir proposer des alternatives. (Autrement dit etre performant n'est pas pour moi une qualite absolue mais relative).Citation:
Envoyé par loufoque
- L'optimisation des classes de base vides + le fait qu'un sizeof ne retourne jamais 0 fait que l'egalite peut etre fausse;Citation:
Envoyé par screetch
On ne peut pas dire que le besoin d'héritage multiple soit courant, mais il existe ici ou là. Ne pas l'avoir à sa disposition peut donc être préjudiciable et aboutir à du code suboptimal, dans ces cas précis et légitimes.
Quant il n'est pas utilisé, il n'a aucun cout (comme toujours en C++).
Quant il est mal utilisé, ben il est mal utilisé, et c'est Mal. Là aussi c'est assez typique du C++, mais c'est un autre débat.
Si j'avais quelque chose à reprocher à cette fonctionnalité en C++, ce serait plutôt au niveau des détails d'implémentation dans les cas non triviaux (héritage virtual, ordre d'initialisation dans les arborescences) que du principe. Certaines utilisations historiques, maintenant heureusement obsolètes, comme l'ajout de traits à un type, ont été avantageusement remplacés par l'utilisation de templates. Donc l'état actuel de l'héritage multiple en C++ me parait tout à fait satisfaisant.
c'est un peu du chipotage la. il y a de fortes chances que les classes de bases ne soient pas vides puisqu'elles contiennent surement une vtable.Citation:
Envoyé par Jean-Marc.Bourguet
Personnellement, je ne vois pas pourquoi je serais contre l'héritage multiple et je ne vois pas pourquoi ce serait un problème de conception, le seul inconvénient, c'est la taille du vtable.
Une alternative, c'est les concepts.Citation:
Envoyé par Jean-Marc.Bourguet
Quand tu déclares une classe, tu fais une assertion qu'elle vérifie les concepts C1...Cn.
Tu peux toujours référencer ton objet par un "pointeur" vers l'interface/concept avec un truc comme adobe::poly.
Le problème étant que des trucs comme adobe::poly ça reste pas terrible, l'idéal ce serait que le langage aide.
Et pour les assertions, je crois pas qu'on puisse les faire à la compilation (quoique avec les constexpr peut-être).
Ou j'ai manque quelque chose dans l'evolution du langage, ou les concepts sont qqch deCitation:
Envoyé par loufoque
statique et j'ai du mal a les considerer comme une alternative a toutes les utilisations de l'heritage multiple. Si tu cherches des alternatives partielles, il y a aussi le CRTP qui permet de lineariser certains cas ou l'heritage multiple est aussi envisageable.
J'ai bien tout lu le topic (ouf), et je ne suis toujours pas sur du sens de cette phrase.Citation:
Envoyé par loufoque
Ce qui est sur c'est que l'on peut faire des assertions à la compilation en C++ ça s'appelle des asserts statiques. Mais dans la mesure où je n'ai pas bien compris ta phrase, il est possible que cela ne contredise pas ce que tu viens de dire.
Quant à savoir si on doit autoriser les héritages multiples, à mon avis, la réponse est "oui", par contre il faudrait interdire aux gens qui s'en servent de coder sur les mêmes projets que moi.
Plus sérieusement, il me parait clair, suite à cette discussion (et aux nombreuses autres sur le sujet) que c'est un concept délicat, et ceci :
- parce que parfois on ne peut pas faire mieux
- parce que souvent on s'en sert n'importe comment
Donc utilisons les héritages multiples, mais avec parcimonie et méfiance.
le principe de adobe::poly, que j'ai cité, c'est de faire des trucs qui ressemblent aux concepts avec du dynamic dispatch.Citation:
Ou j'ai manque quelque chose dans l'evolution du langage, ou les concepts sont qqch de
statique et j'ai du mal a les considerer comme une alternative a toutes les utilisations de l'heritage multiple.
C'était un élément alternatif aux interfaces, pas à l'héritage multiple en général.
Je parlais de faire l'assertion qu'une classe implémente un concept...Citation:
Envoyé par Feriaman
Dans ce cas désolé .. je me disais bien aussi que j'avais du mal comprendre quelque chose.Citation:
Envoyé par loufoque
Bonne soirée.
@Luc Hermitte : merci pour ces précisions. Effectivement le terme "implémentation" était mal choisi de ma part, il s'agirait plus d'héritage d'extension (donc pas de substitualité ici).
@JolyLoïc : effectivement il traite les cas préconditions et post conditions différemment, il considère qu'une précondition de méthode peut/doit être vérifiée par le code client et non dans l'implémentation de la méthode.