IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

[Débat] C++ vs Java


Sujet :

Débats sur le développement - Le Best Of

  1. #1721
    Membre régulier
    Homme Profil pro
    Architecte serveur
    Inscrit en
    septembre 2011
    Messages
    64
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte serveur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2011
    Messages : 64
    Points : 100
    Points
    100
    Par défaut
    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.

    Citation Envoyé par _skip Voir le message
    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 ?"

  2. #1722
    Membre chevronné
    Profil pro
    Développeur Java Indépendant
    Inscrit en
    mai 2007
    Messages
    1 333
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java Indépendant

    Informations forums :
    Inscription : mai 2007
    Messages : 1 333
    Points : 2 052
    Points
    2 052
    Par défaut
    Citation Envoyé par SuperBidi Voir le message
    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é.
    Yoshi

    PS : tous les propos tenus dans le message ci-dessus sont à préfixer avec "A mon humble avis", "Je pense que". Il serait inutilement fastidieux de le rappeler à chaque phrase.

  3. #1723
    Membre actif
    Profil pro
    Inscrit en
    mars 2007
    Messages
    259
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 259
    Points : 299
    Points
    299
    Par défaut
    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.

    Citation Envoyé par GanYoshi Voir le message
    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.

  4. #1724
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 611
    Points
    7 611
    Par défaut
    Citation Envoyé par SuperBidi Voir le message
    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.

  5. #1725
    Membre régulier
    Profil pro
    Développeur informatique
    Inscrit en
    juin 2006
    Messages
    154
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2006
    Messages : 154
    Points : 122
    Points
    122
    Par défaut
    Citation Envoyé par aliasjcdenton Voir le message
    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++!

  6. #1726
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 606
    Points
    5 606
    Par défaut
    Citation Envoyé par CAMIC Voir le message
    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...
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  7. #1727
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 501
    Points : 29 868
    Points
    29 868
    Par défaut
    Citation Envoyé par CAMIC Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #1728
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 173
    Points
    3 173
    Par défaut
    Citation Envoyé par koala01 Voir le message
    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.....
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  9. #1729
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Citation Envoyé par koala01 Voir le message

    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

  10. #1730
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 501
    Points : 29 868
    Points
    29 868
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  11. #1731
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Citation Envoyé par koala01 Voir le message
    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.

  12. #1732
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par koala01 Voir le message
    ..
    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.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  13. #1733
    Membre confirmé
    Profil pro
    Inscrit en
    avril 2006
    Messages
    432
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2006
    Messages : 432
    Points : 578
    Points
    578
    Par défaut
    Stop le HS là (en plus vous dites n'importe quoi)

  14. #1734
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 611
    Points
    7 611
    Par défaut
    Citation Envoyé par Ubiquité Voir le message
    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é.

  15. #1735
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 173
    Points
    3 173
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    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.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  16. #1736
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 909
    Points : 3 173
    Points
    3 173
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    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)
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  17. #1737
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 501
    Points : 29 868
    Points
    29 868
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  18. #1738
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 611
    Points
    7 611
    Par défaut
    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.

    Citation Envoyé par koala01 Voir le message
    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.

  19. #1739
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 501
    Points : 29 868
    Points
    29 868
    Par défaut
    Citation Envoyé par _skip Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  20. #1740
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par koala01 Voir le message
    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..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

Discussions similaires

  1. [Débat] Technologie .NET vs JAVA
    Par neo.51 dans le forum Débats sur le développement - Le Best Of
    Réponses: 1047
    Dernier message: 14/01/2019, 16h15
  2. [Débat] .NET vs JAVA/J2EE
    Par tssi555 dans le forum VB.NET
    Réponses: 5
    Dernier message: 10/12/2008, 07h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo