Discussion :

[SuperBidi]

Je vais développer plus mon propos, parce que malgré tous les votes négatifs, je ne pense pas être totalement à l'ouest. Donc je me laisse un dernier post pour tenter de vous convaincre.

En fait je vais te le dire, ne le prends pas mal mais à mon avis, comme beaucoup de développeur, tu ignores comment les exceptions doivent s'utiliser.

Je suis d'accord. Pas nécessairement avec le fait que je ne sache pas me servir des exceptions (quoi que ce soit possible), mais avec le fait que certains dévs les utilisent n'importe comment. Or, dans un environnement de projet, entre les développeurs légitimement faibles (stagiaires dont on fait passer le code en prod sans grosse révision), les développements légitimement faibles (code de test qui se retrouve en prod sans réécriture), les contraintes de production qui empêchent de prendre le temps nécessaire pour corriger chaque bug au moment ou on le découvre et les démos au client qui doivent marcher quand bien même tout n'est pas codé, je suis tombé sur ce genre de récupérations d'erreurs légères.

Autre exemple, le cycle de vie des objets. En C++ on y échappe pas, vu qu'un objet non initialisé, comme un objet delete ne peut être dissocié d'un objet en vie. En Java, on peut juste faire un test de non nullité.
Je suis donc déjà tombé sur du code Java constellé de tests de non nullité non commentés, sans logs sur le else, et sans même que le dév qui les ai écrits ne sache me dire dans quelles conditions l'objet pouvait être null. Juste, tout le code en était constellé, il en déduisait donc que l'alternative était possible.
Voire, le dév m'a parfois juste répondu que des fois l'objet était null, et qu'il avait loggé la chose. Effectivement, il y avait un log dans son code que personne ne comprenait (pas même lui, fondamentalement, vu qu'il ne savait pourquoi l'objet pouvait être null), et qu'il n'avait juste jamais remonté, alors que tout le monde pensait que le bug lui était dévolu, vu que le log était dans son code.

En C++, ce genre de code léger n'existe pas, et donc les erreurs ne peuvent passer sous silence. Quoi que, dixit un de mes anciens boss, les smartpointers de boost permettent d'éviter un paquet de crash

Quant à passer tous ses dévs au goudron et aux plumes, je paraphraserai un grand penseur moderne : On est tous le bidouilleur de quelqu'un.

Maintenant, l'autre question que tu soulèves est : "Est ce que ce genre d'erreurs peuvent être associées au langage ?"

Je te répondrais par une question : "A quoi cela sert il de catcher un NullPointerException ?"

[GanYoshi]

Je te répondrais par une question : "A quoi cela sert il de catcher un NullPointerException ?"

A rien, à ce que j'ai compris les RuntimeException ne sont généralement pas sensées être catchées puisqu'elle ne sont pas sensés se produire.

Par contre on peut lever une CheckedException si le test de nullité est vérifié.

[kpouer]

SuperBidi, en java on teste si une référence est null, car il est possible qu'un champ d'un objet soit null (si c'est un objet et que tu ne l'as pas initialisé c'est sa valeur par défaut).
Et on peut ne pas avoir systématiquement besoin d'initialiser un champ, peut être qu'on va l'initialiser lors de sa première utilisation d'ou le test à null.
En C++ si tu n'initialise pas ton champ il a la pire des choses, une valeur indéterminée. Ca ne va même pas t'empêcher d'utiliser ce champ et même d'appeler des méthodes dessus, ça ne plantera que lorsqu'une méthode tentera d'accéder à un objet de la classe, et ça le fera à l'exécution.
En java c'est impossible, si tu appelles un méthode sur une variable null, tu as immédiatement un NullPointerException et tu sais que tu as un bug.

A rien, à ce que j'ai compris les RuntimeException ne sont généralement pas sensées être catchées puisqu'elle ne sont pas sensés se produire.

Par contre on peut lever une CheckedException si le test de nullité est vérifié.

Si, ça sert, mais dans des cas exceptionnels. Tout dépend si tu veux que ton programme plante en cas de bug ou si tu veux qu'il continue à tourner.
Tu écris Tomcat par exemple, lorsqu'une page web est appelée, Tomcat appelle la servlet correspondante, il est très probable qu'ils catchent tout, parce qu'ils ne maitrisent pas le code de la servlet (puisqu'il est fourni par un tiers), il ne faudrait pas qu'un bug dans la servlet ferme totalement Tomcat.

[_skip]

mais avec le fait que certains dévs les utilisent n'importe comment. Or, dans un environnement de projet, entre les développeurs légitimement faibles (stagiaires dont on fait passer le code en prod sans grosse révision), les développements légitimement faibles (code de test qui se retrouve en prod sans réécriture), les contraintes de production qui empêchent de prendre le temps nécessaire pour corriger chaque bug au moment ou on le découvre et les démos au client qui doivent marcher quand bien même tout n'est pas codé, je suis tombé sur ce genre de récupérations d'erreurs légères.

Si tu écris une routine one-shot juste pour importer une fois des données ou si tu testes une libraire, c'est compréhensible que tu ne veuilles pas trop perdre de temps sur une gestion d'exception et que tu te contentes d'un catch(Exception e) { e.printStackTrace(); }.
Mais sitôt qu'il s'agit de code que tu livres à des clients, s'il n'a pas un minimum de standard de qualité ben ça te retombera dessus. A mon sens, rien n'est pire dans ce métier que du code faux qui marche "par bol" en développement et qui foire en production avec des conséquences. Et ça c'est le genre de choses auxquelles on s'expose avec des pratiques fumeuses comme celle dont tu parles.

Les délais n'excusent pas tout non plus car faire une gestion d'erreur correcte n'est pas excessivement onéreux, c'est pas ça qui te fait perdre 3 semaines sur un développement de 3 mois.

Autre exemple, le cycle de vie des objets. En C++ on y échappe pas, vu qu'un objet non initialisé, comme un objet delete ne peut être dissocié d'un objet en vie. En Java, on peut juste faire un test de non nullité.
Je suis donc déjà tombé sur du code Java constellé de tests de non nullité non commentés, sans logs sur le else, et sans même que le dév qui les ai écrits ne sache me dire dans quelles conditions l'objet pouvait être null. Juste, tout le code en était constellé, il en déduisait donc que l'alternative était possible.

De nouveau, le meilleur langage au monde ne peut pas pallier à un manque de rigueur ou à de l'inconscience (incompétence?) de la part du développeur. Insérer des tests de nullité silencieux partout c'est encore une superbe manière de faire croire que du code faux fonctionne normalement.

En C++, ce genre de code léger n'existe pas, et donc les erreurs ne peuvent passer sous silence.

Qu'est-ce qui t'empêche de tester si un pointeur est null et le cas échéant de faire un truc bidon ou alors rien du tout?

Maintenant, l'autre question que tu soulèves est : "Est ce que ce genre d'erreurs peuvent être associées au langage ?"

Je te répondrais par une question : "A quoi cela sert il de catcher un NullPointerException ?"

On ne catche pas une NullPointerException, ce genre d'exception est là pour signaler une anomalie, avec stacktrace et tout. En java, tu n'as franchement pas beaucoup de chance d'écrire du code qui fonctionne en cachant la merde au chien sauf si tu te tues à le faire comme dans tes exemples.

Il y a, avec certains langages comme PHP la possibilité de fautes assez subtiles ( comme celles dues à des libertés accordées au développeur sur le typage) que l'on pourrait effectivement mettre sur le dos de son côté permissif.
Mais ce que tu cites là, c'est pas de simples manque d'attention mais carrément des fautes qu'on ne peut pas vraiment commettre involontairement.

[CAMIC]

Mais y-a-t'il une chance pour que C++ soit abandonné un jour ou cela semble-t'il impossible du fait de sa grande popularité mais surtout du fait qu'il n'y a pas (ou peu) d'autres langages natifs aussi puissants ?

Même question pour Java : quelles sont ses chances d'être remplacé un jour, par quoi, etc. ?

Le C++ a encore de beaux jours devant lui, puisque la machine virtuelle de java est écrit en C++!

[hegros]

Le C++ a encore de beaux jours devant lui, puisque la machine virtuelle de java est écrit en C++!

Mouais je ne suis pas expert Java mais qu'est-ce qui empêche d'avoir une vm écrite en Java 'compilé'.

C'est comme dire que le C a de beaux jours devant lui (ce que je ne doute pas) parce que le compilateur C++ est écrit en C....Le premier compilateur sûrement mais plus maintenant...

[koala01]

Le C++ a encore de beaux jours devant lui, puisque la machine virtuelle de java est écrit en C++!

J'aurais surtout tendance à dire que C++ a encore de beaux jours devant lui parce qu'il y a une quantité phénoménale de code écrit en C++ qu'il est irréaliste d'envisager de réécrire

De plus, il n'y a rien à faire, il faut et il faudra toujours -- même si c'est pour des "secteurs de niche"-- des langages qui soient, en tout état de cause beaucoup plus proche de la machine que ce que peut l'être java, même dans sa version compilée.

Ceci dit, on peut en dire autant en ce qui concerne la quantité de code java, surtout quand on voit le nombre de projets à démarrer pour lesquels le choix s'est orienté vers lui

[jabbounet]

J'aurais surtout tendance à dire que C++ a encore de beaux jours devant lui parce qu'il y a une quantité phénoménale de code écrit en C++ qu'il est irréaliste d'envisager de réécrire

De plus, il n'y a rien à faire, il faut et il faudra toujours -- même si c'est pour des "secteurs de niche"-- des langages qui soient, en tout état de cause beaucoup plus proche de la machine que ce que peut l'être java, même dans sa version compilée.

Ceci dit, on peut en dire autant en ce qui concerne la quantité de code java, surtout quand on voit le nombre de projets à démarrer pour lesquels le choix s'est orienté vers lui

je confirme c'est pour la même qu'il existe encore tout un tas de développeur cobol/mainframe aussi. dure pour une entreprise de se débarrasser d'un vieux système quand tout son SI est basé" dessus.....

[kisitomomotene]

De plus, il n'y a rien à faire, il faut et il faudra toujours -- même si c'est pour des "secteurs de niche"-- des langages qui soient, en tout état de cause beaucoup plus proche de la machine que ce que peut l'être java, même dans sa version compilée.

Vue sous cet angle, le C est largement préféré au C++ par la communauté des développeur lorsqu'on veut faire un développement "proche de la machine" . Le C++ a finalement de la peine a trouver sa véritable place, quelque soit le critère de choix que l'on opte (productivité, performance, robustesse, maintenabilité etc) on pourra difficilement choisir le C++ comme langage pour démarrer un nouveau projet, et il ne sera finalement utilisé que pour maintenir du code ancien

[koala01]

Vue sous cet angle, le C est largement préféré au C++ par la communauté des développeur lorsqu'on veut faire un développement "proche de la machine" . Le C++ a finalement de la peine a trouver sa véritable place, quelque soit le critère de choix que l'on opte (productivité, performance, robustesse, maintenabilité etc) on pourra difficilement choisir le C++ comme langage pour démarrer un nouveau projet, et il ne sera finalement utilisé que pour maintenir du code ancien

Je ne suis pas sur du tout!!!

Il ne faut pas croire que, parce que l'on dit "proche de la machine", on parle d'office de drivers, non plus

Je travaille actuellement sur un projet industriel entièrement écrit en C++ qui n'a été démarré il n'y a "que" 5 ans

Je ne doute pas qu'il y aurait sans doute moyen de faire le même projet en java, mais je ne suis pas sur du tout que nous pourrions atteindre le degré de performances obtenu en C++

Dans certaines situations, le recours au garbage collector ou à une machine virtuelle (ou à d'autres obligations apportées par java) n'est, purement et simplement, pas envisageable, mais où l'apport du paradigme OO ou du paradigme générique est indispensable.

Dans de telles situations, le seul langage qui reste, c'est C++

La place de C++ est relativement simple : entre le driver et l'application qui peut se permettre de recourir à une machine virtuelle

Et encore, il y a parfaitement moyen de décider d'écrire un driver avec

[kisitomomotene]

Je ne suis pas sur du tout!!!

Il ne faut pas croire que, parce que l'on dit "proche de la machine", on parle d'office de drivers, non plus

Je travaille actuellement sur un projet industriel entièrement écrit en C++ qui n'a été démarré il n'y a "que" 5 ans

Je ne doute pas qu'il y aurait sans doute moyen de faire le même projet en java, mais je ne suis pas sur du tout que nous pourrions atteindre le degré de performances obtenu en C++

Dans certaines situations, le recours au garbage collector ou à une machine virtuelle (ou à d'autres obligations apportées par java) n'est, purement et simplement, pas envisageable, mais où l'apport du paradigme OO ou du paradigme générique est indispensable.

D'abord je ne pose pas particulièrement le problème sous l'angle C++ vs Java, mais de la place en général de C++ dans l'univers des langages de programmation. Car même si dans certaine perspective C++ est plus adapté que java, on peut trouver un autre langage mieux que C++ pour résoudre le problème dans cette perspective.

Je ne sais pas trop personnellement. Mais si je me fis aux témoignages de certains développeurs de référence ( par exemple le mec qui est à l'initiative de linux) et au vu du classement des langages les plus populaires ( où le C est en passe de devenir le langage n° 1), lorsque les performances, la bonne gestion des ressources sont critiques, les paradigmes OO du C++ apportent beaucoup plus de problèmes qu'ils n'en résolvent, c'est pour cela que dans ces cas beaucoup préfère utiliser directement le C.
Et si dans une application les paradigmes C++ ne posent pas de problèmes, il est fort probable qu'on aurait pu obtenir les mêmes résultats mais avec plus de productivité, de robustesse ou de portabilité si on avait utilisé C# ou Java par exemple.

[souviron34]

..
La place de C++ est relativement simple : entre le driver et l'application qui peut se permettre de recourir à une machine virtuelle

Et encore, il y a parfaitement moyen de décider d'écrire un driver avec

je ne suis pas d'accord avec ton post : lorsqu'on compare, entre les Factory et les initialisations inutiles provoquées par les new, il y a beaucoup d'"overhead" inutiles générées par le C++.

Je pense plus prosaiquement que comme le C++ a été poussé par les formations/universités et que les jeunes du début des années 2000 ne juraient que par le C++, en jetant aux oubliettes le C (pouah. C'est pas un langage objet) , un certain nombre d'industries ont basculé vers le C++ par manque de main-d'oeuvre et formation inadéquate des dirigeants de l'époque.

Mais pour en faire depuis 23 ans tout en n'étant pas un "systémique", je ne vois pas en quoi le C serait plus réservé aux drivers : je n'ai jamais écrit de driver de ma vie, et toutes les appls que j'ai faites sont "haut-niveau"..

Je ne sais pas compter en hexa ni en octal, je n'ai jamais programmé sur un kernel, et pourtant j'ai plus de 6 millions de lignes de code en C à mon actif..

Pour moi le C sert à faire des applis performantes, avec des facilités d'optimisation, dans un langage que tout scientifique comprend, comme le Fortran. Et avec un paradigme de fonctionalités, ce qui est très nettement plus correspondant à ce que pense un scientifique que le paradigme objet.

[Ubiquité]

Stop le HS là (en plus vous dites n'importe quoi)

[_skip]

Stop le HS là (en plus vous dites n'importe quoi)

Euh non, ils ne disent pas n'importe quoi et plusieurs intervenants sur cette page ont beaucoup de bouteille. Comme tu dis ça, c'est quand même un peu fort de café.

[jabbounet]

Je ne sais pas trop personnellement. Mais si je me fis aux témoignages de certains développeurs de référence ( par exemple le mec qui est à l'initiative de linux) et au vu du classement des langages les plus populaires ( où le C est en passe de devenir le langage n° 1), lorsque les performances, la bonne gestion des ressources sont critiques, les paradigmes OO du C++ apportent beaucoup plus de problèmes qu'ils n'en résolvent, c'est pour cela que dans ces cas beaucoup préfère utiliser directement le C.

Ce que dit un "développeur de référence" sur le langage C++ c'est son opinion il faut la respecter, mais ce n'est pas la seule, d'autres "développeurs de référence" ont d'autres opinion qu'il faut aussi respecter.

Prendre un concept la ou il est inutile conduit aux problèmes, utiliser un outil que l'on ne maitrise pas conduit aux problèmes....

Exemple bidon mais qui illustre bien, dans ma boite à outil j'ai une perceuse, un tournevis et un marteau. Si je dois percer un trou je choisi la perceuse. de même pour les développements mes choix sont d'essayer de prendre l'outil le plus adapté à mon besoin parmi les outils dont je dispose.

Si je ne sais pas me servir de ma perceuse, soit je prends le temps de comprendre comment elle marche avant de l'utiliser soit je ne l'utilise pas, si je l'utilise sans savoir comment ca marche je risque de faire n'importe quoi et potentiellement de me blesser.

Pour en revenir à notre cas

Un langage est un outil qui te permet de réaliser l'application que tu dois réaliser, ne pas maitriser son outil conduit souvent aux problèmes.
Une partie non négligeable des soucis que j'ai vu sur les projets et ce quelque soit le langage (c/c++/java/fortran/lisp/shell/...) étaient liés à une incompréhension du langage, ou des concepts permettant de réaliser l'application, les utilisations à contre emploi de certaines idées/concept sont aussi ne source de bétises (percer un trou avec le marteau de la boite a outil)...

Ces erreurs ont tendance à disparaitre souvent quand les outils/concepts sont maitrisés. Chaque langages tente d'apporter ses réponses à des concepts les autres étant à implémenter, libre a toi de les utiliser ou non, de les implémenter ou non quand ils ne sont pas présent.

[jabbounet]

Et si dans une application les paradigmes C++ ne posent pas de problèmes, il est fort probable qu'on aurait pu obtenir les mêmes résultats mais avec plus de productivité, de robustesse ou de portabilité si on avait utilisé C# ou Java par exemple.

C# portable, pas vu sur HP-ux, sun/solaris,...?

C et C++ sont parfaitement portable si tu as tu t'impose une certaine discipline que t'impose d'autres technos.

java peu ne pas être supporté par certains matériels spécifiques si aucune jvm n'a été porté sur ce type de palteforme, et si tu sors des standards tu peux avoirs soucis avec la porta comme pour les autres langage.
exemple utiliser des trucs dans java.sun.misc et ensuite devoir porter ton application sur une jvm non différente de celle de sun (oracle maintenant)

[koala01]

Je ne sais pas trop personnellement. Mais si je me fis aux témoignages de certains développeurs de référence ( par exemple le mec qui est à l'initiative de linux) et au vu du classement des langages les plus populaires ( où le C est en passe de devenir le langage n° 1), lorsque les performances, la bonne gestion des ressources sont critiques, les paradigmes OO du C++ apportent beaucoup plus de problèmes qu'ils n'en résolvent, c'est pour cela que dans ces cas beaucoup préfère utiliser directement le C.

Je vois exactement de quoi tu veux parler

Et ce dont tu parles n'a qu'un seul mérite : celui de prouver que même les génies peuvent avoir leurs lacunes et dire des idioties

Malgré tout le respect que j'ai pour lui, Tovald n'a jamais rien compris au paradigme OO et n'y comprendra sans doute jamais rien!!!

Je suis le premier à dire qu'il est particulièrement facile de faire des erreurs en voulant utiliser le paradigme OO, et que c'est d'autant plus vrai quand le langage a décidé de ne pas imposer de limites arbitraires à sa manière de le mettre en oeuvre.

Mais il ne faut pas jeter bébé avec l'eau du bain : Le problème n'est pas le paradigme objet, ni le paradigme générique!!! le problème est la méconnaissance des principes qui sont d'applications.

Et si dans une application les paradigmes C++ ne posent pas de problèmes, il est fort probable qu'on aurait pu obtenir les mêmes résultats mais avec plus de productivité, de robustesse ou de portabilité si on avait utilisé C# ou Java par exemple.

Pour ce qui est de la portabilité, elle est très certainement bien plus au rendez vous avec C++ ou avec java (enfin, grace à la VM quand meme ) qu'avec C#, et, pour les autres (robustesse et productivité), je peux t'assurer qu'elles peuvent parfaitement être présentes avec C++

Je reconnais cependant qu'il faut être beaucoup plus attentif à respecter les principes OO en C++ car il n'a pas, contrairement aux autres langages cités, imposé de restriction aribraire

Peut etre me diras tu que c'est la grande force de java ou de C# que d'avoir su imposer ces restrictions arbitraires (je pense, entre autres, à l'interdiction de l'héritage multiple, mais pas seulement ), mais, de mon avis (qui n'engage bien sur que moi ) c'est leur plus gros défaut, car cela a pour conséquence de faire croire à certains concepteurs / développeurs / programmeurs qu'ils sont parfaitement compétants alors qu'ils sont d'une incompétence crasse!!!

N'importe qui est en mesure d'assimiler très rapidement la syntaxe de n'importe quel langage, mais ce n'est pas pour autant que la programmation doit être considérée comme "facile"

Il est assez frappant de constater que la réponse que la plupart des gens apportent à la question "quelle est la base de la programmation OO" et l'encapsulation, alors que la base de la programmation OO est en réalité... la subsituabilité (comprend : le fait qu'un objet de n'importe quel type héritant d'une classe de base puisse "passer pour" un objet de la classe de base elle-même).

Le problème des langages comme Java, c'est qu'ils ont décidé de faire en sorte que tout objet créé héritera d'office d'une classe de base commune (Object).

Tu me demanderas sans doute où est le problème la réponse est simple : il est dans le fait que, du coup, il t'est tout à fait possible de demander de manipuler une pomme et une voiture de la même manière (en les considérant comme des Object) alors qu'il n'y a aucun point commun entre ces deux types particuliers.

Le deuxième problème, même s'il s'agit d'un cas d'utilisation rare, est qu'il devient impossible de décider de faire en sorte qu'un type particulier hérite de deux classes distinctes car cela impliquerait le fait que le type en question aurait deux représentations de la classe de base de ces deux classes distinctes.

Or, il n'y a aucune raison objective (hormis un problème de conception à la base) pour vouloir imposer une telle limite dans le paradigme OO

Enfin, le fait d'imposer le fait que tout soit d'office objet (que l'on doive créer un objet contenant la fonction principale) est en lui-même quelque part aberrant, car il n'y a strictement aucune raison d'interdire la création de fonction libres, étant donné que le paradigme OO utilise malgré tout le paradigme impératif

Enfin, bref...

Tout cela pour dire que, à mon avis (qui n'engage que moi, bien sur ) java ou C# ne sont pas de mauvais langages en tant que tel, mais ils ont fait des choix qui sont discutables du point de vue de la conception elle-même.

Pour finir, je dirai que si l'on commençait surtout par apprendre les principes OO (et je ne parle même pas des principes évolués, seulement de LSP, demeter ou encore la responsabilité unique ) à quiconque veut aborder un langage objet, et par leur faire comprendre la nécessité de les suivre, il y aurait déjà beaucoup moins de problèmes à tout point de vue

[_skip]

Tout à fait d'accord au sujet de Torvald. Enfin c'est son avis, j'ai lu à plusieurs reprises des trucs de ce genre venant de programmeurs C.

Mais il ne faut pas jeter bébé avec l'eau du bain : Le problème n'est pas le paradigme objet, ni le paradigme générique!!! le problème est la méconnaissance des principes qui sont d'applications.
Pour ce qui est de la portabilité, elle est très certainement bien plus au rendez vous avec C++ ou avec java (enfin, grace à la VM quand meme ) qu'avec C#, et, pour les autres (robustesse et productivité), je peux t'assurer qu'elles peuvent parfaitement être présentes avec C++

Pour utiliser régulièrement java et C++, il faut quand même bien reconnaître que java est très fort niveau toolchain, tu as du débuggage, du refactoring avancé, la documentation intégrée selon le standard javadoc dans tout IDE et avec toutes les librairies tierces que tu utilises.
Il y a aussi les temps de compilation qui n'ont rien à voir. Pour le même temps que je compile un projet de 30 classes basé sur boost (~50 secondes), je peux compiler facilement 5mo de code java. Enfin ces petites choses (outillage, monde très homogène etc...) jouent quand même un peu sur la productivité.
Je pense qu'à niveau de développeur égal, java et C# sont quand même plus productifs que C++.

Le problème des langages comme Java, c'est qu'ils ont décidé de faire en sorte que tout objet créé héritera d'office d'une classe de base commune (Object).

Tu me demanderas sans doute où est le problème la réponse est simple : il est dans le fait que, du coup, il t'est tout à fait possible de demander de manipuler une pomme et une voiture de la même manière (en les considérant comme des Object) alors qu'il n'y a aucun point commun entre ces deux types particuliers.

Là il faut être attentif à ce que Object définit en tant que tel, grosso-modo une méthode hashcode(), une méthode equals(), et une méthode toString(). En gros ça a trois conséquences :

1) Chaque objet peut être converti en chaîne, par défaut le type et l'adresse sont imprimés.
2) Chaque objet peut être testé d'égalité avec un autre (par défaut l'égalité est basée sur l'adresse, comme une égalité de pointeur c++).
3) Tout objet peut potentiellement être clé ou valeur d'une map.

Donc contrairement à ce que tu sembles penser ça ne donne pas à la voiture une méthode toCompote() ni à la pomme une méthode freine(), ça définit juste un cadre minimal d'interaction entre les objets au sein du framework de base. C'est pas complètement idiot en fait comme choix de conception, et d'ailleurs chez Qt on a aussi choisi de tout faire hériter d'un QObject, ça permet au framework de s'appuyer sur une série de fonctions de base.

Tu peux manipuler une voiture et une pomme dans une collection, même si les collections d'objets hétérogènes sont de plus en plus considérées comme une hérésie à juste titre, cependant, sans cast tu devras te contenter de ce qui est présent dans Object. Tout comme tu peux créer une collection de void* en C++. Cependant il est clair que dans les 2 cas et peu importe le langage en somme, si tu dois trop souvent caster des objets il faut te demander si ta conception est réellement la bonne.

Enfin, le fait d'imposer le fait que tout soit d'office objet (que l'on doive créer un objet contenant la fonction principale) est en lui-même quelque part aberrant, car il n'y a strictement aucune raison d'interdire la création de fonction libres, étant donné que le paradigme OO utilise malgré tout le paradigme impératif

C'est facilement contourné avec les fonctions statiques et ça peut résoudre les problèmes de "scope" de fonctions. Enfin c'est peut être discutable mais ça n'introduit pas directement de limitations contrairement à l'héritage multiple.

Tout cela pour dire que, à mon avis (qui n'engage que moi, bien sur ) java ou C# ne sont pas de mauvais langages en tant que tel, mais ils ont fait des choix qui sont discutables du point de vue de la conception elle-même.

Et bien en fait, il y a plusieurs éléments, je suis d'accord par exemple que ne pas permettre une fonctionnalité pour la seule raison que les gens pourraient mal l'utiliser, ce qu'on entend souvent au sujet de la surcharge d'opérateur, c'est un peu dommage. Ensuite vouloir contraindre est peut être aussi un compromis, est-ce qu'il faut rendre les outils et compilateurs impossibles et indémerdables de lenteur pour supporter une fonctionnalité dont plein de gens peuvent (voire "sont vivement encouragés à") se passer.

Enfin voilà, je peux pas te donner tort sur le fond, toutefois je pense qu'il y a un équilibre entre les libertés accordées, les performances de compilation et la frustration utilisateur à trouver. Et chacun le ressent différemment.

[koala01]

Là il faut être attentif à ce que Object définit en tant que tel, grosso-modo une méthode hashcode(), une méthode equals(), et une méthode toString(). En gros ça a trois conséquences :

1) Chaque objet peut être converti en chaîne, par défaut le type et l'adresse sont imprimés.
2) Chaque objet peut être testé d'égalité avec un autre (par défaut l'égalité est basée sur l'adresse, comme une égalité de pointeur c++).
3) Tout objet peut potentiellement être clé ou valeur d'une map.

Si ce n'est qu'il n'y a pas forcément lieu de faire en sorte que toute chose puisse être clé dans une map, et il n'y a absolument aucune raison de permettre de comparer une pomme avec une voiture (même si, par défaut, c'est au niveau de l'adresse que la comparaison a lieu )

Donc contrairement à ce que tu sembles penser ça ne donne pas à la voiture une méthode toCompote() ni à la pomme une méthode freine(), ça définit juste un cadre minimal d'interaction entre les objets au sein du framework de base. C'est pas complètement idiot en fait comme choix de conception, et d'ailleurs chez Qt on a aussi choisi de tout faire hériter d'un QObject, ça permet au framework de s'appuyer sur une série de fonctions de base.

Je n'ai pas dit que cela permet à une pomme d'avoir une fonction freine, j'ai dit que tu peux appeler les fonctions présentées par Object (essentiellement equals ) en ayant d'un coté une pomme et de l'autre une voiture...

Or, cela n'a strictement aucun sens

Tu peux manipuler une voiture et une pomme dans une collection, même si les collections d'objets hétérogènes sont de plus en plus considérées comme une hérésie à juste titre, cependant, sans cast tu devras te contenter de ce qui est présent dans Object.

Mais, justement, pourquoi rendre cette hérésie possible

Tout comme tu peux créer une collection de void* en C++.

Cela fait des années que l'on répète de ne pas le faire, et de préférer, au pire, le paradigme générique (voir des classes comme boost::any )

Cependant il est clair que dans les 2 cas et peu importe le langage en somme, si tu dois trop souvent caster des objets il faut te demander si ta conception est réellement la bonne.

Le problème, c'est qu'avec java, si tu te demande quel est le plus petit commun à deux classes, tu retomberas systématiquement sur Object, alors qu'en C++, tu restes libre de décider quel est ce plus petit commun (avec, il est vrai, le risque de partir sur un God Object equivalent )

C'est facilement contourné avec les fonctions statiques et ça peut résoudre les problèmes de "scope" de fonctions. Enfin c'est peut être discutable mais ça n'introduit pas directement de limitations contrairement à l'héritage multiple.

Les fonctions et variables statiques ont déjà quelque chose d'aberrant quand on y pense!!!

Les développeurs plus ou moins aguerris ont tellement l'habitude de les utiliser qu'ils ne s'en rendent même plus compte, mais, quand il s'agit de lire l'explication à leur sujet, il y a de quoi devenir chêvre :

Nous sommes dans un contexte dans lequel "tout est objet", et on nous dit que c'est une fonction qui ne dépend d'aucun objet en particulier du type en question, mais qui est partagée par l'ensemble des objets et qui appartient pourtant à la classe!!!

Il faut, tu l'avoueras, s'accrocher pour arriver à s'y retrouver, non

Quant à l'héritage multiple, s'il est correctement envisagé, il n'apporte pas plus de limitations que l'héritage simple

Car, même dans les cas tordus où l'on souhaiterait pouvoir faire hériter une classe de deux classes distinctes ayant la même classe de base, il est tout à fait possible d'éviter la duplication des données propres à cette classe de base

Je l'admet cependant volontiers, cela nécessite une attention de tous les instants quand on décide de recourir à l'héritage multiple (mais il faut déjà, en théorie, être particulièrement attentif quand on envisage l'héritage simple )

Et bien en fait, il y a plusieurs éléments, je suis d'accord par exemple que ne pas permettre une fonctionnalité pour la seule raison que les gens pourraient mal l'utiliser, ce qu'on entend souvent au sujet de la surcharge d'opérateur, c'est un peu dommage. Ensuite vouloir contraindre est peut être aussi un compromis, est-ce qu'il faut rendre les outils et compilateurs impossibles et indémerdables de lenteur pour supporter une fonctionnalité dont plein de gens peuvent (voire "sont vivement encouragés à") se passer.

Je ne pourrais pas le prouver n'ayant pas de chiffres "dignes de foi" sous la main, mais, selon moi, la lenteur de l'outil est bien plus due à l'héritage de la chaine de compilation du C (préprocesseur, compilateur, éditeur de liens) qu'à C++ lui-même

Ce n'est pas pour rien que l'on parle pour la norme "qui suivra" celle qui vient de paraitre, de la mise au point de "modules" dont le but est, justement, d'éviter d'avoir à recompiler les 7300 fichiers qui incluent de manière directe ou indirecte un fichier d'en-tête parce que ce dernier a changé

Enfin voilà, je peux pas te donner tort sur le fond, toutefois je pense qu'il y a un équilibre entre les libertés accordées, les performances de compilation et la frustration utilisateur à trouver. Et chacun le ressent différemment.

C'est la raison pour laquelle, si je me permet d'être critique envers java, je n'en suis pas pour autant sectaire au point de le déconseiller à tout le monde

[souviron34]

Ce n'est pas pour rien que l'on parle pour la norme "qui suivra" celle qui vient de paraitre, de la mise au point de "modules" dont le but est, justement, d'éviter d'avoir à recompiler les 7300 fichiers qui incluent de manière directe ou indirecte un fichier d'en-tête parce que ce dernier a changé

euh.. Ce n'est pas pour rien que ça s'appelle des "dépendances" dans le Makefile...

En ce qui concerne les fichiers d'entête..


Maintenant, lorsque j'ai vu tourner des compils en C++ sur de (très)gros projets, en fait il semble que le temps est surtout passé à aller explorer puis ré-explorer les définitions de classes..

Sans doute parce que la philosophie sous-jacente est d'avoir une clase dans un fichier... Et que ça peut finir par faire beaucoup beaucoup..


Je pense que ce genre de problème est beaucoup plus dû à cette manière de découper ses fichiers (donc à une application stricte de la philosophie OO) que à la chaîne de compilation, qui, elle, DOIT s'apercevoir qu'une dépendance à changé et que donc le module doit être recompilé...

J'espère que la chaîne de traitement et la fonctionalité du Makefile et des dépendances ne changera pas.. C'est un super outil et une excellente chose..