Version imprimable
Bonjour à tous,
on entend souvent dire des choses comme:
1/ "visual ne respecte pas la norme, mais il s'en approche de plus en plus"
2/ "gcc respecte la norme à 100%, quelle que soit la version"
3/ "le seul compilo qui respecte la norme à 100% c'est le Comeau"
En voulant clarifier tout ça, je me suis lancé dans quelques recherches, mais je n'ai pas trouvé grand-chose.
Qu'en pensez-vous? Auriez-vous quelques liens pertinents sur le sujet?
:merci:
1] Effectivement, Visual .NET 2005 ne respecte pas la norme quant aux membres des classes de base d'une classe template par exemple.
2] Ca par contre c'est faux :p Il ne supporte déjà pas la séparation des déclarations et définitions des templates (via le mot clé export), même dans la dernière version (au passage je ne sais pas si un compilateur le supportant existe).
La série des versions 3.3 de gcc ne respecte pas la norme quant aux membres des classes de base d'une classe template par exemple (même problème que celui que j'ai cité pour VIsual), etc ..
Changelog gcc 3.4 liste pas mal de choses qui ne respectaient pas la norme.
3] Aucune idée je ne l'ai jamais utilisé.
Je pense que les listes de report de bug des différents compilos devraient contenir pas mal d'informations, après c'est vrai qu'il faut faire le tri entre bug du compilo et non respect des normes
1) Il faut séparer la version 6, dont le respect de la norme est mauvais car sortie avant elle, des versions 7 et 8 dont le respect de la norme est dans une bonne moyenne.
2) Non, voir 3) ;).
3) Oui, au bug près.
c'est vrai que visual s'en approche. Ils ont corrigé de nombreux defauts dans la prochaine version, Orcas, mais je ne sais pas encore ou ca en est
GCC s'approche beaucoup du respect de la norme dans les versions 4.0
Comeau est reputé pour avoir un respect parfait de la norme.
Depusi la version 4 j'ai arreté de chercher les differences entre GCC et Comeau, je continue a trouver du non respect chez visual.
Salut,
Je crois qu'il faut peut être déjà préciser si on parle du respect pur et dur de la norme, ou de la sensation que l'on en a à l'usage...
Dans le sujet FAQ->liste d'initialisation, par exemple, il y a un débat sur l'utilité de donner ou non un avertissement quand le respect de la norme implique que le compilateur interprète le code de manière différente (ex: un membre qui sera initialisé après un autre) de ce que le codeur a écrit, et, principalement, quand le respect de la norme ne prête pas à conséquence.
A titre personnel, sur ce sujet, j'aurais tendance à faire plus confiance à un compilo qui me signalera systématiquement que j'approche de la "ligne rouge" qu'à un compilo qui ne me le signalera que... quand je l'ai dépassée, mais c'est un avis qui n'engage que moi :P
Ensuite, il est clair qu'il faut veiller à comparer ce qui est comparable... On ne peut pas demander à un compilateur sorti (par exemple) en 2000 de respecter une norme qui serait sortie (par exemple) en 2001 :P
Enfin, et sans vouloir faire dégénérer le débat en "qui préfère quel compilateur", et sans passer sur les opinions purement philosophiques des licences d'utilisation, je ferai naturellement plus confiance en un compilateur qui évolue rapidement (une "nouvelle" "sous version" tous les quelques mois) et qui ne fait pas mystères des problèmes qu'il rencontre vis à vis du respect de la norme qu'à un compilateur qui laisse croire que tout va bien chez lui, merci beaucoup :P
Quand à savoir lequel respecte le mieux la norme... je n'ai pas d'avis objectif sur la question :P
Effectivement Koala il y a une distinction à faire au niveau respect pur et dur de la norme et avertissement de l'utilisateur sur le fait que le compilo ne fera pas ce que cet utilisateur souhaite afin justement de respecter la norme.
Concernant l'évolution des compilateurs, il vaut voir aussi les enjeux lorsque l'on corrige un bug. Le cas que j'ai cité (problème d'accès aux membres d'une classe de base pour les classes templates) en est une bonne illustration : si un compilo buggé à ce niveau là veut corriger ce bug, il casse du code existant.
C'est le choix qu'a fait gcc, en fournissant les corrections à apporter au code. Maintenant peut être que d'autres compilos préfèreront signaler que ce type de code n'est pas en accord avec la norme sans pour autant empêcher sa compilation, pour ne pas casser l'existant. Ce sont deux approches qui ont chacune leurs avantages et leurs inconvénients, à partir de là il n'y a aucune raison, même si chacun exprime ses préférences, que le sujet dérive vers un débat du style "tel compile est mieux qu'un autre"
Ma réponse avait à vrai dire comme but de faire comprendre que je trouve que Gcc me *semble* mieux respecter la norme, mais que c'est un "ressenti" purement subjectif en dehors de toute comparaison avec les problèmes connus pour les différents compilateurs à ce sujet ;)
Tous les compilos ne respectent pas la norme, et ce que l'on pourrait en attendre, sur les mêmes points.
Et sorti de choses assez obscures et pointues (genre utiliser le SFINAE pour détecter si un type est pourvu d'un opérateur d'injection vers std::ostream qui m'avait fait planter GCC 3.3/3.4 et pas VC 2005 Express), aujourd'hui on n'observe plus trop de différences.
Regarder les warnings gérés et générés est effectivement un autre élément discriminant.