Ca fait 10 ans que j'écrit du soft a longueur de journée, pas une seule fois je me suis dit "'tin ca serait cool si ma class "véhicule" pouvaitetre a la fois une "moto" et une "voiture"". Parce que c'est un peu a ca que se resume l'heritage multiple.
Le moment ou t'as besoin de ca, c'est quasi certainement parce que t'as foire ton modele objet, et que tu subclasses essentiellement pour partager du code (ou pire, des attributs), ce qui est la premiere raison pour laquelle ne PAS subclasser.
Ensuite, les raisonnement a la "si t'en as pas besoin, l'utilises pas" ca aide pas. Juste parce que Java a fait l'erreur d'être trop simple et pas assez flexible (dans une certain mesure, en tout cas ils auraient certainement pu évoluer en 20 ans), ca justifie pas la foire a la saucisse qu'est le c++.
Ca a un coup sur le temps de compilation (c'est pas pour rien que le c++ est repute pour être monstrueusement lent a compiler), ca a un coup sur la qualité des compilateurs, ca fait chier parce que yaura toujours un gros malin qq part pour se croire plus malin et s'en servir.
Ca construit un monstre a 3 têtes ou chaque ligne de code peut avoir tellement d'implication et de choses cachées que ca devient très dur de comprendre a la fois ce qu'il se passe réellement et quelle était l'intention du developeur.
Empiler les modes de passages d'argument avec des choix de designs plus que douteux (ne t'en sert pas!), les new vs les malloc (ne t'en sert pas!), se retrouver avec une syntaxe non context free parce que quelqu'un a pense que c'était une bonne idée d'implicitement allouer les objets (ne t'en sert pas!), le modèle d'exception foireux (ne t'en sert pas!), les opérateurs surcharges (ne t'en sert pas!), les templates qui te pondent des messages d'erreurs plus long qu'un jour sans pain (ne t'en sert pas!), l'ABI a la mord moi le noeud (ne t'en sert... heu, ouais, la ca va être dur), c'est bien joli, mais ca n'a aucune coherence et toutes ces features que t'es pas cense utiliser, ben un jour tu vas te retrouver avec du code qui l'utilise.
Parce que le gars qui bossait la avant toi se sentait oblige d'affirmer son intelligence supérieure, parce que du code tiers que tu peux pas faire autrement que de l'utiliser s'en sert. Si tu bosses tout seul dans ton coin, oui, tu peux t'en sortir. Mais si tu bosses tout seul dans ton coin, on est en droit de se demander pourquoi tu choisis qq chose d'aussi complique que le c++ pour des gains douteux a cette echelle.
Du C ou de l'objective c te donne du natif rapide qui est très gerable a l'échelle d'une personne, avec autant si ce n'est plus de souplesse, et si tu veux de la flexibilité, va voir du cote de ruby/python ou les JVM languages qui ont le vent en poupe en ce moment.
[^] # Re: ==
Posté par groumly . En réponse au journal OSv : l'OS pour les nuages. Évalué à 5.
Ca fait 10 ans que j'écrit du soft a longueur de journée, pas une seule fois je me suis dit "'tin ca serait cool si ma class "véhicule" pouvaitetre a la fois une "moto" et une "voiture"". Parce que c'est un peu a ca que se resume l'heritage multiple.
Le moment ou t'as besoin de ca, c'est quasi certainement parce que t'as foire ton modele objet, et que tu subclasses essentiellement pour partager du code (ou pire, des attributs), ce qui est la premiere raison pour laquelle ne PAS subclasser.
Ensuite, les raisonnement a la "si t'en as pas besoin, l'utilises pas" ca aide pas. Juste parce que Java a fait l'erreur d'être trop simple et pas assez flexible (dans une certain mesure, en tout cas ils auraient certainement pu évoluer en 20 ans), ca justifie pas la foire a la saucisse qu'est le c++.
Ca a un coup sur le temps de compilation (c'est pas pour rien que le c++ est repute pour être monstrueusement lent a compiler), ca a un coup sur la qualité des compilateurs, ca fait chier parce que yaura toujours un gros malin qq part pour se croire plus malin et s'en servir.
Ca construit un monstre a 3 têtes ou chaque ligne de code peut avoir tellement d'implication et de choses cachées que ca devient très dur de comprendre a la fois ce qu'il se passe réellement et quelle était l'intention du developeur.
Empiler les modes de passages d'argument avec des choix de designs plus que douteux (ne t'en sert pas!), les new vs les malloc (ne t'en sert pas!), se retrouver avec une syntaxe non context free parce que quelqu'un a pense que c'était une bonne idée d'implicitement allouer les objets (ne t'en sert pas!), le modèle d'exception foireux (ne t'en sert pas!), les opérateurs surcharges (ne t'en sert pas!), les templates qui te pondent des messages d'erreurs plus long qu'un jour sans pain (ne t'en sert pas!), l'ABI a la mord moi le noeud (ne t'en sert... heu, ouais, la ca va être dur), c'est bien joli, mais ca n'a aucune coherence et toutes ces features que t'es pas cense utiliser, ben un jour tu vas te retrouver avec du code qui l'utilise.
Parce que le gars qui bossait la avant toi se sentait oblige d'affirmer son intelligence supérieure, parce que du code tiers que tu peux pas faire autrement que de l'utiliser s'en sert. Si tu bosses tout seul dans ton coin, oui, tu peux t'en sortir. Mais si tu bosses tout seul dans ton coin, on est en droit de se demander pourquoi tu choisis qq chose d'aussi complique que le c++ pour des gains douteux a cette echelle.
Du C ou de l'objective c te donne du natif rapide qui est très gerable a l'échelle d'une personne, avec autant si ce n'est plus de souplesse, et si tu veux de la flexibilité, va voir du cote de ruby/python ou les JVM languages qui ont le vent en poupe en ce moment.