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.
| > > 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.
Une erreur, dans cette contexte, c'est quelque chose que les auteurs n'ont pas fait exprès. Si g++ n'implémente pas export, ce n'est pas parce que quelqu'un s'est trompé dans le codage de ce qu'ils intendaient implémenter, mais plutôt suite à une décision consciente (d'allocation de ressources, etc.).
Dans le cas de Comeau et d'Intel, les auteurs ont essayé d'implémenter tout, de façon conforme. Parce qu'ils sont des êtres humains, il y a bien des erreurs par ci et par là, où le compilateur ne se comporte pas comme ils entendaient. Mais ce sont des erreurs, non des decisions conscientes.
-- 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
Gabriel Dos Reis wrote:
"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.
Une erreur, dans cette contexte, c'est quelque chose que les
auteurs n'ont pas fait exprès. Si g++ n'implémente pas export,
ce n'est pas parce que quelqu'un s'est trompé dans le codage de
ce qu'ils intendaient implémenter, mais plutôt suite à une
décision consciente (d'allocation de ressources, etc.).
Dans le cas de Comeau et d'Intel, les auteurs ont essayé
d'implémenter tout, de façon conforme. Parce qu'ils sont des
êtres humains, il y a bien des erreurs par ci et par là, où le
compilateur ne se comporte pas comme ils entendaient. Mais ce
sont des erreurs, non des decisions conscientes.
--
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
| > > 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.
Une erreur, dans cette contexte, c'est quelque chose que les auteurs n'ont pas fait exprès. Si g++ n'implémente pas export, ce n'est pas parce que quelqu'un s'est trompé dans le codage de ce qu'ils intendaient implémenter, mais plutôt suite à une décision consciente (d'allocation de ressources, etc.).
Dans le cas de Comeau et d'Intel, les auteurs ont essayé d'implémenter tout, de façon conforme. Parce qu'ils sont des êtres humains, il y a bien des erreurs par ci et par là, où le compilateur ne se comporte pas comme ils entendaient. Mais ce sont des erreurs, non des decisions conscientes.
-- 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
kanze
Fabien LE LEZ wrote:
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.
En effet. 98% est un de ces chiffres qui sortent souvent comme ça. C'est comme quand on te dit qu'il n'y a plus qu'une semaine de travail pour finir le projet -- j'ai déjà vecu des projets où il n'y avait plus qu'une semaine pendant plus d'un an.
Ce n'est jamais 96%. Ni 8 journées de travail. (Sauf, évidemment, si on mesure réelement.)
-- 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
Fabien LE LEZ wrote:
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.
En effet. 98% est un de ces chiffres qui sortent souvent comme
ça. C'est comme quand on te dit qu'il n'y a plus qu'une semaine
de travail pour finir le projet -- j'ai déjà vecu des projets
où il n'y avait plus qu'une semaine pendant plus d'un an.
Ce n'est jamais 96%. Ni 8 journées de travail. (Sauf,
évidemment, si on mesure réelement.)
--
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
| 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.
En effet. 98% est un de ces chiffres qui sortent souvent comme ça. C'est comme quand on te dit qu'il n'y a plus qu'une semaine de travail pour finir le projet -- j'ai déjà vecu des projets où il n'y avait plus qu'une semaine pendant plus d'un an.
Ce n'est jamais 96%. Ni 8 journées de travail. (Sauf, évidemment, si on mesure réelement.)
-- 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
Dans le cas de Comeau et d'Intel, les auteurs ont essayé d'implémenter tout, de façon conforme.
Je me trompe ou c'est plutôt Edison qui a essayé de faire ça dans son frontal EDG ? Si je ne m'abuse Comeau et Intel sont des wrappers de EDG.
-- Alain
Dans le cas de Comeau et d'Intel, les auteurs ont essayé
d'implémenter tout, de façon conforme.
Je me trompe ou c'est plutôt Edison qui a essayé de faire ça dans son
frontal EDG ?
Si je ne m'abuse Comeau et Intel sont des wrappers de EDG.
Dans le cas de Comeau et d'Intel, les auteurs ont essayé d'implémenter tout, de façon conforme.
Je me trompe ou c'est plutôt Edison qui a essayé de faire ça dans son frontal EDG ? Si je ne m'abuse Comeau et Intel sont des wrappers de EDG.
-- Alain
James Kanze
Alain Gaillard wrote:
Dans le cas de Comeau et d'Intel, les auteurs ont essayé d'implémenter tout, de façon conforme.
Je me trompe ou c'est plutôt Edison qui a essayé de faire ça dans s on frontal EDG ? Si je ne m'abuse Comeau et Intel sont des wrappers de EDG.
Wrapper, ce n'est sûrement pas le mot qui convient, mais il se sert effectivement du front-end de EDG, et c'est EDG, dans les deux cas, qui a réelement implémenté le langage.
-- James Kanze 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:
Dans le cas de Comeau et d'Intel, les auteurs ont essayé
d'implémenter tout, de façon conforme.
Je me trompe ou c'est plutôt Edison qui a essayé de faire ça dans s on
frontal EDG ? Si je ne m'abuse Comeau et Intel sont des wrappers de
EDG.
Wrapper, ce n'est sûrement pas le mot qui convient, mais il se
sert effectivement du front-end de EDG, et c'est EDG, dans les
deux cas, qui a réelement implémenté le langage.
--
James Kanze kanze.james@neuf.fr
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
Dans le cas de Comeau et d'Intel, les auteurs ont essayé d'implémenter tout, de façon conforme.
Je me trompe ou c'est plutôt Edison qui a essayé de faire ça dans s on frontal EDG ? Si je ne m'abuse Comeau et Intel sont des wrappers de EDG.
Wrapper, ce n'est sûrement pas le mot qui convient, mais il se sert effectivement du front-end de EDG, et c'est EDG, dans les deux cas, qui a réelement implémenté le langage.
-- James Kanze 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
