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
Discussion :
Il existe des outils pour la qualité logicielle qui permettent de détecter ce genre de choses. Je ne dis pas que c'est le top et que c'est facile à utiliser, mais si ce genre de problèmes te coûte du temps, ce peut être une solution.Envoyé par Christuff
Salut,
Je crois qu'il faut commencer par rendre à Cesar ce qui appartient à Cesar, ou plutôt, par ne rendre C++ responsable que de... ce dont il est responsable.
J'ai en effet lu sur la première page de nombreuses interventions qui semblaient rendre C++ responsables de ce que les gens en font, parmi lesquelles (à peu près dans l'ordre dans lequel elles sont apparues) :
- Les gens qui enseignent/pratiquent le C++ comme du C
- Les différentes implémentations des compilateurs ...
- J'en pointerais un beaucoup plus simple: l'illisibilité...
- Pas d'éditeur aussi puissant qu'on peut en trouver dans le monde Java par exemple
- les écarts et omissions des différents compilos par rapport au standard
Comprenons ce sont les utilisateurs et / ou les gens qui implémentent le compilateur les vrais responsables de ces travers:
1 -Si les gens pratiquent et enseignent C++ comme du C, c'est peut être en partie du à sa filiation historique avec C, mais c'est surtout du au fait que de trop nombreux enseignants / développeurs n'ont pas encore jugé utile de... se remettre en question...
2 et 5 - Le respect et le support très inégale de la norme n'est du... qu'aux développeurs de compilateur, dont certains étaient connus à une époque pour leur habitude de faire fi des normes.
Notez cependant que les choses évoluent dans le bon sens, car la plupart des fournisseurs de compilateur dont je parle ont changé leur fusil d'épaule, et tendent à faire en sorte de suivre la norme par défaut.
Notez que l'utilisateur a aussi sa part de responsabilités, dans le sens où C et C++ sont sans doute les seuls langages pour lesquels il continue à utiliser des compilateurs vieux de plus de dix ans...
3 - L'illisibilité du code : Il est vrai que C++ permet de rendre un code illisible, mais, encore une fois, c'est un choix du programmeur que de le faire.
On ne peut reprocher un code illisible... qu'au programmeur qui l'a écrit.
De plus, il est tout à fait possible d'écrire du code illisible dans n'importe quel langage
4 - L'absence d'éditeurs "aussi puissant que ce que l'on trouve en java" est beaucoup plus du au fait qu'on ne trouve personne pour les créer qu' au langage lui-même
Vous me direz sans doute que, si C++ ne laissait pas la porte ouverte à tous ces problèmes, ils (ces problèmes) n'existeraient pas.
Mais bon, le code de la route interdit aussi de rouler à plus de 120 ou 130 (selon le pays) sur l'autoroute, ce n'est pas pour cela que personne ne le fait
Ça rend la relecture vachement simple, quand on veut savoir à quoi sert une variable en milieu de programme, on remonte au début de la fonction et elle est là (commentée bien entendu). Rien à voir avec des questions de rapidité ou propreté.
Tout a fait. Nous sommes dans les années 2010 et un environnement de développement se doit d'être un minimum "idiot proof". Ca inclut l'IDE, le compilo et les specs du langage.
Comme ça a été dit, c'est terminé le temps où seuls les barbus névropathes avaient la science nécessaire pour coder une boucle for().
Aujourd'hui les développeurs se doivent d'apprendre un langage en un temps très court avec pour seul guide les tutoriels, docs, exemples, ... Pas le temps d'apprendre les concepts, fondements et autres paradigmes qui sous-tendent le fonctionnement.
La programmation était un art, c'est aujourd'hui un job.
Donc si le C++ permet trop facilement de se tirer une balle dans le pied et d'y laisser sa jambe, et bien il y a fort à parier que les équipes seront pleines d'unijambistes.
j'ai souffert des même problèmes en C++, puis dans un élan de motivation je suis passé au D. Ce langage corrige de nombreuse critique décrite par mes collègues précédemment.
Maintenant en D ce que je peux lui reprocher ces ça jeunesse, en effet de nombreuses élément sont proposé nativement ou dans la bibliothèque standard mais elle ne couvre forcément pas des cas précis. Ce qui ne m'empêche pas de l'avoir adopté.
Il se fait que, justement, les documents qui proposent à l'apprentissage du code parfaitement lisible sont malgré tout la grande majorité.Tout a fait. Nous sommes dans les années 2010 et un environnement de développement se doit d'être un minimum "idiot proof". Ca inclut l'IDE, le compilo et les specs du langage.
Comme ça a été dit, c'est terminé le temps où seuls les barbus névropathes avaient la science nécessaire pour coder une boucle for().
Aujourd'hui les développeurs se doivent d'apprendre un langage en un temps très court avec pour seul guide les tutoriels, docs, exemples, ... Pas le temps d'apprendre les concepts, fondements et autres paradigmes qui sous-tendent le fonctionnement.
La programmation était un art, c'est aujourd'hui un job.
Donc si le C++ permet trop facilement de se tirer une balle dans le pied et d'y laisser sa jambe, et bien il y a fort à parier que les équipes seront pleines d'unijambistes.
Mais combien de programmeurs perdent des heures entières à supprimer tout retour à la ligne et toute indentation uniquement "pour faire ch... le voisin" et parce que le langage leur permet
Le langage se doit, effectivement, d'être plus ou moins idot-proof, mais est-ce à lui d'empêcher ses utilisateurs d'être c
On ne peut pas empecher une dev de faire volontairement de l'obfuscation. Par contre il faudrait l'empecher de le faire par inadvertance.Il se fait que, justement, les documents qui proposent à l'apprentissage du code parfaitement lisible sont malgré tout la grande majorité.
Mais combien de programmeurs perdent des heures entières à supprimer tout retour à la ligne et toute indentation uniquement "pour faire ch... le voisin" et parce que le langage leur permet
Le langage se doit, effectivement, d'être plus ou moins idot-proof, mais est-ce à lui d'empêcher ses utilisateurs d'être c
Par exemple, en Java, j'ai toujours trouvé choquant qu'une variable et une méthode puissent avoir le même nom, sans déclencher le moindre warning du compilo.
A l'inverse, le C++ génère tellement de warning qu'on n'y fait plus vraiment attention. Il y a meme des flags de compilation pour gérer le niveau de warning.
Ce serait donc un argument en faveur de C++, ca, nonOn ne peut pas empecher une dev de faire volontairement de l'obfuscation. Par contre il faudrait l'empecher de le faire par inadvertance.
Par exemple, en Java, j'ai toujours trouvé choquant qu'une variable et une méthode puissent avoir le même nom, sans déclencher le moindre warning du compilo.
A titre personnel (et je connais pas mal d'intervenants qui font pareilA l'inverse, le C++ génère tellement de warning qu'on n'y fait plus vraiment attention. Il y a meme des flags de compilation pour gérer le niveau de warning.
Je conçois que certains aient une approche différente, mais, encore une fois, il ne faut pas rendre le langage responsable de l'incurie de ceux qui l'utilisent
volontairement c'est idiot, c++ est un langage qui, compilé, ne permet pas de retrouver le code source d'origine, pas comme java par exemple.
Je fais de même, mais trop de gens se disent "c'est un warning alors osef". Le problème se situe clairement entre la chaise et le clavier.A titre personnel (et je connais pas mal d'intervenants qui font pareil
Exactement...
C'est pour cela que je plaide pour qu'on ne rende le langage (quel qu'il soit) responsable que de ... ce qui est de sa responsabilité.
Il n'y a rien à faire, il y a les "bons" programmeurs et les... moins bons (voir médiocres).
Aucun langage ne pourra transformer les moins bons d'un coup de baguette magique, aussi balisé puisse-t-il être dans sa philosophie
Tout au plus, il est possible que le langage permette de cacher la médiocrité du programmeur ou du développeur... Mais c'est, à mon sens, le pire service qu'il puisse leur rendre (et surtout qu'il puisse rendre à la société qui les utilise
Pour ceux que les développements autour du C/C++ intéressent :
The LLVM Compiler Infrastructure
Pitié, arrêtez d'écrire « C/C++ » : malgré l'historique qui les lie, ce sont deux langages différents !
En plus de vous discréditer, ça entretient une confusion qui n'a pas lieu d'être.
EDIT : Ce message n'était pas destiné à mon voisin du dessus, mais aux quelques messages précédents.
arrêtez de crier au loup sans avoir été voir le site en question…
c'est vous qui vous vous discréditez…
le projet LLVM concerne C, C++ et même Objective-C…
(et même à travers GCC les autres langages supportés par celui-ci…)
LLVM support également le D avec LDC
D'ailleur dans fedora 14 il y aura intégration de LDC et tango pour dev en D.
j'espère aussi d'autre bibliotheque D.
Oui et non. Le C++ génère surement un warning pour ce problème (en fait, j'en sais rienCe serait donc un argument en faveur de C++, ca, non
Il y a des tas de choses qui ne peuvent pas être interdites à cause de la rétrocompatibilité avec C.Oui et non. Le C++ génère surement un warning pour ce problème (en fait, j'en sais rien
C'est bien le problème. Il n'existe pas de C++ "strictement" Objet. Seul la volonté du programmeur permet de maintenir le respect des règles de ce paradigme de programmation.
Le C++ n'est pas un langage Objet, "strictement" ou pas. Ce n'est pas son but. C'est un langage multi-paradigme, où l'on essaye de choisir le bon paradigme pour résoudre le problème, et pas désespérement de coller le problème dans un paradigme quelconque.
On peut considérer ça comme un défaut (pour tous les gens endoctrinés au sacro-saint objet, ça demande de réfléchir différement, code pas forcèment homogène) ou comme un avantage (ça permet de résoudre le problème au "mieux", on n'est pas "bridé" par le design du langage ...). (Et non le pur objet n'est pas la réponse à tous les problèmes informatiques comme on voudrait bien le faire croire).
Quand je vois "void*" dans un code en C++, je commence à m'inquièter sérieusement à la base.
Je crois que tu confond ce qui est interdit avec ce dont tu estime que cela ne devrait pas être autorisé.Oui et non. Le C++ génère surement un warning pour ce problème (en fait, j'en sais rien
Il n'y a rien à faire, ce qui est interdit doit provoquer une erreur. Pour le reste...
Le souhait de garder une compatibilité aussi grande que possible avec le C est une décision qui ne sera sans doute jamais remise en question, qui implique qu'il faille "faire avec" dans certaines situations.
Le principal problème rencontré est alors que l'on ne peut pas décider d'interdire quelque chose qui soit autorisé en C, même s'il s'agit de quelque chose qui n'est décidément pas conseillé en C++.
De plus, Ce n'est pas parce que, dans ta vision des choses, une manière de procéder ne devrait pas être autorisée (sans doute parce que tu ne t'es jamais trouvé face à une situation dans laquelle tu n'avais pas le choix) que d'autres n'ont pas besoin de cette possibilités dans des situations bien particulières et en toute connaissance de cause.
Il est donc "logique" que la décision de recourir à cette possibilité produise un avertissement ("attention, si vous persistez dans cette voie, soyez sur de ce que vous faites") et non une erreur.
Au final, le principal problème de C++ (ou du moins la base de tous ses problèmes) est peut être sa philosophie de maintenir à tout prix une compatibilité accrue avec C.
Mais, comme je l'ai dit, c'est un aspect qui ne semble pas près à être rediscuter
Répondre avec citation
Partager