Je voudrais amener la discussion sur un post que j'ai lu dans
comp.lang.c++.moderated.
Quelqu'un pose une question à partir d'un éventuel bug de VC++ 2005 et
la discussion ne semble pas trancher catégoriquement.
Soit ce code:
int main()
{
size_t n = 8;
return n;
}
Notez bien l'absence de tout include.
VC++ 2005 compile ça sans broncher.
Pourtant selon 18.1 (draft 2005) il semble bien clair que size_t est
défini dans cstddef, lequel sur ce point est identique à stddef.h.
Il me semble bien que le standard C dit sans ambiguïté que stddef.h contient
typedef unsigned int size_t;
Encore plus étonnant, le stddef.h de VC++, inclus par cstddef ne
contient même pas le typedef (à moins que je n'ai la berlue)
AMHA le compilateur n'a pas à connaître size_t avant qu'on le lui ai
déclaré, et AMHA toujours c'est clairement un bug.
Oui. Mais si je fais un compilateur où comme j'indique que mon message sera constitué d'une chaîne vide en cas d'erreur, et d'une chaîne vide en cas de succès, je pense que j'ai formellement rempli les contraintes du standard.
Je ne pense pas quand même. Supposons qu'en cas de succès un compilo ne sorte rien, quand le standard dit "a conforming implementation shall issue at least one diagnostic message," je ne pense pas qu'il faille comprendre une chaîne vide. Le message est à priori pour l'utilisateur humain et une chaîne vide n'est pas exploitable pour l'humain qui ne peut même pas différencier erreur et succès.
Tel que je comprends le standard, l'implémentation est libre du contenu du message, mais encore faut-il qu'il y ait un contenu.
-- Alain
Oui. Mais si je fais un compilateur où comme j'indique que mon message
sera constitué d'une chaîne vide en cas d'erreur, et d'une chaîne vide
en cas de succès, je pense que j'ai formellement rempli les contraintes
du standard.
Je ne pense pas quand même.
Supposons qu'en cas de succès un compilo ne sorte rien, quand le
standard dit "a conforming implementation shall issue at least one
diagnostic message," je ne pense pas qu'il faille comprendre une chaîne
vide. Le message est à priori pour l'utilisateur humain et une chaîne
vide n'est pas exploitable pour l'humain qui ne peut même pas
différencier erreur et succès.
Tel que je comprends le standard, l'implémentation est libre du contenu
du message, mais encore faut-il qu'il y ait un contenu.
Oui. Mais si je fais un compilateur où comme j'indique que mon message sera constitué d'une chaîne vide en cas d'erreur, et d'une chaîne vide en cas de succès, je pense que j'ai formellement rempli les contraintes du standard.
Je ne pense pas quand même. Supposons qu'en cas de succès un compilo ne sorte rien, quand le standard dit "a conforming implementation shall issue at least one diagnostic message," je ne pense pas qu'il faille comprendre une chaîne vide. Le message est à priori pour l'utilisateur humain et une chaîne vide n'est pas exploitable pour l'humain qui ne peut même pas différencier erreur et succès.
Tel que je comprends le standard, l'implémentation est libre du contenu du message, mais encore faut-il qu'il y ait un contenu.
-- Alain
Gabriel Dos Reis
Alain Gaillard writes:
| | > Oui. Mais si je fais un compilateur où comme j'indique que mon | > message sera constitué d'une chaîne vide en cas d'erreur, et d'une | > chaîne vide en cas de succès, je pense que j'ai formellement rempli | > les contraintes du standard. | | Je ne pense pas quand même. | Supposons qu'en cas de succès un compilo ne sorte rien, quand le | standard dit "a conforming implementation shall issue at least one | diagnostic message," je ne pense pas qu'il faille comprendre une | chaîne vide. Le message est à priori pour l'utilisateur humain et une | chaîne vide n'est pas exploitable pour l'humain qui ne peut même pas | différencier erreur et succès.
La norme n'interdit pas à un compilo d'émettre un diagnostic même lorsque le programme est valide et le compilo l'a accepté.
|
| > Oui. Mais si je fais un compilateur où comme j'indique que mon
| > message sera constitué d'une chaîne vide en cas d'erreur, et d'une
| > chaîne vide en cas de succès, je pense que j'ai formellement rempli
| > les contraintes du standard.
|
| Je ne pense pas quand même.
| Supposons qu'en cas de succès un compilo ne sorte rien, quand le
| standard dit "a conforming implementation shall issue at least one
| diagnostic message," je ne pense pas qu'il faille comprendre une
| chaîne vide. Le message est à priori pour l'utilisateur humain et une
| chaîne vide n'est pas exploitable pour l'humain qui ne peut même pas
| différencier erreur et succès.
La norme n'interdit pas à un compilo d'émettre un diagnostic même
lorsque le programme est valide et le compilo l'a accepté.
| | > Oui. Mais si je fais un compilateur où comme j'indique que mon | > message sera constitué d'une chaîne vide en cas d'erreur, et d'une | > chaîne vide en cas de succès, je pense que j'ai formellement rempli | > les contraintes du standard. | | Je ne pense pas quand même. | Supposons qu'en cas de succès un compilo ne sorte rien, quand le | standard dit "a conforming implementation shall issue at least one | diagnostic message," je ne pense pas qu'il faille comprendre une | chaîne vide. Le message est à priori pour l'utilisateur humain et une | chaîne vide n'est pas exploitable pour l'humain qui ne peut même pas | différencier erreur et succès.
La norme n'interdit pas à un compilo d'émettre un diagnostic même lorsque le programme est valide et le compilo l'a accepté.
-- Gaby
Gabriel Dos Reis
"Dominique Vaufreydaz" writes:
| Bonjour, | | > Mais comme VC++2005 n'émet strictement aucun message il devrait | > rejeter ce code, donc il est buggué. C'est en tout cas comme ça que | > je lit le standard. Ais je tort Gaby ? | | Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a | un compilo qui respecte toute la norme ? A ma connaissance non. | Pour le compilo de Visual C++, microsoft affirme respecter 98% | (de memoire) de la norme.
comment fais-tu les mesures ?
-- Gaby
"Dominique Vaufreydaz" <Doms@invalid> writes:
| Bonjour,
|
| > Mais comme VC++2005 n'émet strictement aucun message il devrait
| > rejeter ce code, donc il est buggué. C'est en tout cas comme ça que
| > je lit le standard. Ais je tort Gaby ?
|
| Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a
| un compilo qui respecte toute la norme ? A ma connaissance non.
| Pour le compilo de Visual C++, microsoft affirme respecter 98%
| (de memoire) de la norme.
| Bonjour, | | > Mais comme VC++2005 n'émet strictement aucun message il devrait | > rejeter ce code, donc il est buggué. C'est en tout cas comme ça que | > je lit le standard. Ais je tort Gaby ? | | Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a | un compilo qui respecte toute la norme ? A ma connaissance non. | Pour le compilo de Visual C++, microsoft affirme respecter 98% | (de memoire) de la norme.
comment fais-tu les mesures ?
-- Gaby
Gabriel Dos Reis
"kanze" writes:
| Dominique Vaufreydaz wrote: | | > > Mais comme VC++2005 n'émet strictement aucun message il devrait | > > rejeter ce code, donc il est buggué. C'est en tout cas comme ça que | > > je lit le standard. Ais je tort Gaby ? | | > Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a | > un compilo qui respecte toute la norme ? A ma connaissance non. | | Comeau et Intel, modulo erreurs.
si nous devons compter « modulo erreurs », pratiquement tous les compilos sont qualifiés.
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
| Dominique Vaufreydaz wrote:
|
| > > Mais comme VC++2005 n'émet strictement aucun message il devrait
| > > rejeter ce code, donc il est buggué. C'est en tout cas comme ça que
| > > je lit le standard. Ais je tort Gaby ?
|
| > Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a
| > un compilo qui respecte toute la norme ? A ma connaissance non.
|
| Comeau et Intel, modulo erreurs.
si nous devons compter « modulo erreurs », pratiquement tous les
compilos sont qualifiés.
| Dominique Vaufreydaz wrote: | | > > Mais comme VC++2005 n'émet strictement aucun message il devrait | > > rejeter ce code, donc il est buggué. C'est en tout cas comme ça que | > > je lit le standard. Ais je tort Gaby ? | | > Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a | > un compilo qui respecte toute la norme ? A ma connaissance non. | | Comeau et Intel, modulo erreurs.
si nous devons compter « modulo erreurs », pratiquement tous les compilos sont qualifiés.
-- Gaby
Fabien LE LEZ
On 22 Aug 2006 15:36:44 +0200, Gabriel Dos Reis :
| Comeau et Intel, modulo erreurs.
si nous devons compter « modulo erreurs », pratiquement tous les compilos sont qualifiés.
Y'a quand même une différence entre : - l'éditeur ne veut pas implémenter telle ou telle fonctionnalité ; si tu en as besoin, va voir ailleurs ; - il reste des bugs dans le compilo ; si tu en rencontres un, tu peux t'adresser à l'éditeur, avec une bonne chance qu'il le répare.
On 22 Aug 2006 15:36:44 +0200, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
| Comeau et Intel, modulo erreurs.
si nous devons compter « modulo erreurs », pratiquement tous les
compilos sont qualifiés.
Y'a quand même une différence entre :
- l'éditeur ne veut pas implémenter telle ou telle
fonctionnalité ; si tu en as besoin, va voir ailleurs ;
- il reste des bugs dans le compilo ; si tu en rencontres un, tu
peux t'adresser à l'éditeur, avec une bonne chance qu'il le répare.
si nous devons compter « modulo erreurs », pratiquement tous les compilos sont qualifiés.
Y'a quand même une différence entre : - l'éditeur ne veut pas implémenter telle ou telle fonctionnalité ; si tu en as besoin, va voir ailleurs ; - il reste des bugs dans le compilo ; si tu en rencontres un, tu peux t'adresser à l'éditeur, avec une bonne chance qu'il le répare.
Dominique Vaufreydaz
Bonjour,
Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a un compilo qui respecte toute la norme ? A ma connaissance non. Pour le compilo de Visual C++, microsoft affirme respecter 98% (de memoire) de la norme.
comment fais-tu les mesures ?
Demandez a Microsoft. J'ai dit "Microsoft affirme..."
Doms.
Bonjour,
Non, il ne supporte pas toute la norme... D'ailleurs est-ce
qu'il y a un compilo qui respecte toute la norme ? A ma
connaissance non. Pour le compilo de Visual C++, microsoft
affirme respecter 98% (de memoire) de la norme.
comment fais-tu les mesures ?
Demandez a Microsoft. J'ai dit "Microsoft affirme..."
Non, il ne supporte pas toute la norme... D'ailleurs est-ce qu'il y a un compilo qui respecte toute la norme ? A ma connaissance non. Pour le compilo de Visual C++, microsoft affirme respecter 98% (de memoire) de la norme.
comment fais-tu les mesures ?
Demandez a Microsoft. J'ai dit "Microsoft affirme..."
Doms.
Fabien LE LEZ
On 22 Aug 2006 15:34:59 +0200, Gabriel Dos Reis :
| Pour le compilo de Visual C++, microsoft affirme respecter 98% | (de memoire) de la norme.
comment fais-tu les mesures ?
C'est MS qui l'affirme, pas Dominique.
Je me demande s'ils ont balancé ce chiffre "au pif", ou s'il ont soigneusement mis au point une méthode de calcul permettant effectivement de donner ce chiffre.
On 22 Aug 2006 15:34:59 +0200, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
| Pour le compilo de Visual C++, microsoft affirme respecter 98%
| (de memoire) de la norme.
comment fais-tu les mesures ?
C'est MS qui l'affirme, pas Dominique.
Je me demande s'ils ont balancé ce chiffre "au pif", ou s'il ont
soigneusement mis au point une méthode de calcul permettant
effectivement de donner ce chiffre.
| Pour le compilo de Visual C++, microsoft affirme respecter 98% | (de memoire) de la norme.
comment fais-tu les mesures ?
C'est MS qui l'affirme, pas Dominique.
Je me demande s'ils ont balancé ce chiffre "au pif", ou s'il ont soigneusement mis au point une méthode de calcul permettant effectivement de donner ce chiffre.
kanze
Alain Gaillard wrote:
Oui. Mais si je fais un compilateur où comme j'indique que mon message sera constitué d'une chaîne vide en cas d'erreur, et d'une chaîne vide en cas de succès, je pense que j'ai formellement rempli les contraint es du standard.
Je ne pense pas quand même. Supposons qu'en cas de succès un compilo ne sorte rien,
Ce qui n'est pas exigé, et ce qui est rarement le cas. À titre d'exemple (mais je ne connais pas d'autre qui font mieux), g++ documente qu'est diagnostique au sens de la norme tout texte qui sort sur les sorties standard ou l'erreur standard. Ce qui comprend pas mal d'avertissements, etc.
Selon la norme, un compilateur doit sortir une diagnostique pour certaines erreurs. (Et il est obligé à documenter ce qui est diagnostique.) En revanche, il ne lui est pas interdit de sortir la même diagnostique quand il n'y a pas d'erreur.
Logiquement, à titre de la qualité d'implémentation, je m'attendrais à ce que 1) l'implémentation fournisse un moyen de distinguer clairement entre les diagnostiques formelles et d'autres messages, 2) qu'elle documente et ce moyen et les options de compilation qui rendent le compilateur conforme, et 3) qu'il n'émet un message documenté diagnostique que s'il y a réelement une erreur (selon la norme) dans le code (mais c'est tout à fait acceptable d'en émettre une diagnostique dans des cas d'erreur où la norme n'exige pas de diagnostique). Selon ces expectations, g++ est lamentable. Et les autres compilateurs que je connais ne font même pas aussi bien que lui.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard wrote:
Oui. Mais si je fais un compilateur où comme j'indique que mon message
sera constitué d'une chaîne vide en cas d'erreur, et d'une chaîne vide
en cas de succès, je pense que j'ai formellement rempli les contraint es
du standard.
Je ne pense pas quand même.
Supposons qu'en cas de succès un compilo ne sorte rien,
Ce qui n'est pas exigé, et ce qui est rarement le cas. À titre
d'exemple (mais je ne connais pas d'autre qui font mieux), g++
documente qu'est diagnostique au sens de la norme tout texte qui
sort sur les sorties standard ou l'erreur standard. Ce qui
comprend pas mal d'avertissements, etc.
Selon la norme, un compilateur doit sortir une diagnostique pour
certaines erreurs. (Et il est obligé à documenter ce qui est
diagnostique.) En revanche, il ne lui est pas interdit de sortir
la même diagnostique quand il n'y a pas d'erreur.
Logiquement, à titre de la qualité d'implémentation, je
m'attendrais à ce que 1) l'implémentation fournisse un moyen de
distinguer clairement entre les diagnostiques formelles et
d'autres messages, 2) qu'elle documente et ce moyen et les
options de compilation qui rendent le compilateur conforme, et
3) qu'il n'émet un message documenté diagnostique que s'il y a
réelement une erreur (selon la norme) dans le code (mais c'est
tout à fait acceptable d'en émettre une diagnostique dans des
cas d'erreur où la norme n'exige pas de diagnostique). Selon ces
expectations, g++ est lamentable. Et les autres compilateurs que
je connais ne font même pas aussi bien que lui.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oui. Mais si je fais un compilateur où comme j'indique que mon message sera constitué d'une chaîne vide en cas d'erreur, et d'une chaîne vide en cas de succès, je pense que j'ai formellement rempli les contraint es du standard.
Je ne pense pas quand même. Supposons qu'en cas de succès un compilo ne sorte rien,
Ce qui n'est pas exigé, et ce qui est rarement le cas. À titre d'exemple (mais je ne connais pas d'autre qui font mieux), g++ documente qu'est diagnostique au sens de la norme tout texte qui sort sur les sorties standard ou l'erreur standard. Ce qui comprend pas mal d'avertissements, etc.
Selon la norme, un compilateur doit sortir une diagnostique pour certaines erreurs. (Et il est obligé à documenter ce qui est diagnostique.) En revanche, il ne lui est pas interdit de sortir la même diagnostique quand il n'y a pas d'erreur.
Logiquement, à titre de la qualité d'implémentation, je m'attendrais à ce que 1) l'implémentation fournisse un moyen de distinguer clairement entre les diagnostiques formelles et d'autres messages, 2) qu'elle documente et ce moyen et les options de compilation qui rendent le compilateur conforme, et 3) qu'il n'émet un message documenté diagnostique que s'il y a réelement une erreur (selon la norme) dans le code (mais c'est tout à fait acceptable d'en émettre une diagnostique dans des cas d'erreur où la norme n'exige pas de diagnostique). Selon ces expectations, g++ est lamentable. Et les autres compilateurs que je connais ne font même pas aussi bien que lui.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard
La norme n'interdit pas à un compilo d'émettre un diagnostic même lorsque le programme est valide et le compilo l'a accepté.
-- Gaby
Oui, bien sûr. Ce n'est pas ce que je voulais dire.
-- Alain
La norme n'interdit pas à un compilo d'émettre un diagnostic même
lorsque le programme est valide et le compilo l'a accepté.
-- Gaby
Oui, bien sûr. Ce n'est pas ce que je voulais dire.
La norme n'interdit pas à un compilo d'émettre un diagnostic même lorsque le programme est valide et le compilo l'a accepté.
-- Gaby
Oui, bien sûr. Ce n'est pas ce que je voulais dire.
-- Alain
Cyrille
Bonjour,
export ; où en est-il avec des templates à paramètre de template ou la recherche des noms à deux phases ? Avec le VC++ du Visual Studios 2005, ça affiche 3.14159, alors que la norme exige 3. C'est quand même une chose assez fondamentale. Je ne sais pas l'unité de mesure, mais a priori, j'ai du mal déjà à accepter 98% sans export. Et sans la recherche à deux phases... 80% ? Voire moins.
Ca depends si export et la recherche a deux phases sont chacune 1 regle sur 100 ;-P
De toute façons la norme fait plusieurs centaines de pages, plus de 800 si je ne m'abuse. 2% non implémenté, ça fait donc au moins 16 pages, ce qui doit suffire pour contenir les spécifications de export et de la recherche à deux phases (je dis ça sans regarder).
Selon la norme, une implémentation doit documenter les messages ; il me semble normal (et implicitement exigé) qu'elle documente comment il faut invoquer le compilateur pour qu'il soit plus ou moins conforme. (Avec VC++, par exemple, il faut au moins « cl /GR /EHs /vmg ». À cet égard, j'aime bien
J'aurais dit aussi /Zc:ForScope pour la portée des variables déclarées dans un for.
/Zc:forScope est activé par défaut, maintenant, heureusement. Sinon il y a /Za pour désactiver certaines extensions Microsoft.
Tiens, j'ai pas trouvé dans l'IDE le moyen d'activier (hors options mise a la main), /vmg.
Pas la peine de chercher, l'aide indique qu'on ne peut l'activer que à la main dans la boîte "Additional Options".
-- Les lois sont toujours utiles à ceux qui possèdent et nuisibles à ceux qui n'ont rien. ~ Rousseau, du Contrat Social.
Bonjour,
export ; où en est-il avec des templates à paramètre de
template ou la recherche des noms à deux phases ?
Avec le VC++ du Visual Studios 2005, ça affiche 3.14159, alors
que la norme exige 3. C'est quand même une chose assez
fondamentale. Je ne sais pas l'unité de mesure, mais a priori,
j'ai du mal déjà à accepter 98% sans export. Et sans la
recherche à deux phases... 80% ? Voire moins.
Ca depends si export et la recherche a deux phases sont
chacune 1 regle sur 100 ;-P
De toute façons la norme fait plusieurs centaines de pages, plus de 800
si je ne m'abuse. 2% non implémenté, ça fait donc au moins 16 pages, ce
qui doit suffire pour contenir les spécifications de export et de la
recherche à deux phases (je dis ça sans regarder).
Selon la norme, une implémentation doit documenter les
messages ; il me semble normal (et implicitement exigé) qu'elle
documente comment il faut invoquer le compilateur pour qu'il
soit plus ou moins conforme. (Avec VC++, par exemple, il faut au
moins « cl /GR /EHs /vmg ». À cet égard, j'aime bien
J'aurais dit aussi /Zc:ForScope pour la portée des variables
déclarées dans un for.
/Zc:forScope est activé par défaut, maintenant, heureusement.
Sinon il y a /Za pour désactiver certaines extensions Microsoft.
Tiens, j'ai pas trouvé dans l'IDE le
moyen d'activier (hors options mise a la main), /vmg.
Pas la peine de chercher, l'aide indique qu'on ne peut l'activer que à
la main dans la boîte "Additional Options".
--
Les lois sont toujours utiles à ceux qui possèdent et nuisibles à ceux
qui n'ont rien. ~ Rousseau, du Contrat Social.
export ; où en est-il avec des templates à paramètre de template ou la recherche des noms à deux phases ? Avec le VC++ du Visual Studios 2005, ça affiche 3.14159, alors que la norme exige 3. C'est quand même une chose assez fondamentale. Je ne sais pas l'unité de mesure, mais a priori, j'ai du mal déjà à accepter 98% sans export. Et sans la recherche à deux phases... 80% ? Voire moins.
Ca depends si export et la recherche a deux phases sont chacune 1 regle sur 100 ;-P
De toute façons la norme fait plusieurs centaines de pages, plus de 800 si je ne m'abuse. 2% non implémenté, ça fait donc au moins 16 pages, ce qui doit suffire pour contenir les spécifications de export et de la recherche à deux phases (je dis ça sans regarder).
Selon la norme, une implémentation doit documenter les messages ; il me semble normal (et implicitement exigé) qu'elle documente comment il faut invoquer le compilateur pour qu'il soit plus ou moins conforme. (Avec VC++, par exemple, il faut au moins « cl /GR /EHs /vmg ». À cet égard, j'aime bien
J'aurais dit aussi /Zc:ForScope pour la portée des variables déclarées dans un for.
/Zc:forScope est activé par défaut, maintenant, heureusement. Sinon il y a /Za pour désactiver certaines extensions Microsoft.
Tiens, j'ai pas trouvé dans l'IDE le moyen d'activier (hors options mise a la main), /vmg.
Pas la peine de chercher, l'aide indique qu'on ne peut l'activer que à la main dans la boîte "Additional Options".
-- Les lois sont toujours utiles à ceux qui possèdent et nuisibles à ceux qui n'ont rien. ~ Rousseau, du Contrat Social.
