Discussion :

[r0d]

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?

[bolhrak]

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

[Sylvain Togni]

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.

[screetch]

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.

[koala01]

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

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

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

Quand � savoir lequel respecte le mieux la norme... je n'ai pas d'avis objectif sur la question

[bolhrak]

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"

[koala01]

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