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.
La norme ne dit pas qu'il doit refuser de compiler le programme : juste émettre un diagnostic. Maintenant, ce qui constitue un diagnostic est laissé à l'appréciation de l'implémentation.
Oui c'est vrai. J'ai manqué de précision. Je n'aurais pas du dire "rejeter" radicalement effectivement. Cela étant si j'en crois 1.3.3 et 1.5.2 le compilo *doit* émettre un message dans notre cas. Et alors après oui, il peut accepter de compiler ou non.
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 ?
-- Alain
La norme ne dit pas qu'il doit refuser de compiler le programme :
juste émettre un diagnostic. Maintenant, ce qui constitue un diagnostic
est laissé à l'appréciation de l'implémentation.
Oui c'est vrai. J'ai manqué de précision. Je n'aurais pas du dire
"rejeter" radicalement effectivement. Cela étant si j'en crois 1.3.3 et
1.5.2 le compilo *doit* émettre un message dans notre cas. Et alors
après oui, il peut accepter de compiler ou non.
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 ?
La norme ne dit pas qu'il doit refuser de compiler le programme : juste émettre un diagnostic. Maintenant, ce qui constitue un diagnostic est laissé à l'appréciation de l'implémentation.
Oui c'est vrai. J'ai manqué de précision. Je n'aurais pas du dire "rejeter" radicalement effectivement. Cela étant si j'en crois 1.3.3 et 1.5.2 le compilo *doit* émettre un message dans notre cas. Et alors après oui, il peut accepter de compiler ou non.
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 ?
-- Alain
Fabien LE LEZ
On Mon, 21 Aug 2006 11:55:36 +0200, Alain Gaillard :
Cela étant si j'en crois 1.3.3 et 1.5.2 le compilo *doit* émettre un message dans notre cas.
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
On Mon, 21 Aug 2006 11:55:36 +0200, Alain Gaillard
<alain_gaillard28@hotmail.fr>:
Cela étant si j'en crois 1.3.3 et
1.5.2 le compilo *doit* émettre un message dans notre cas.
C'est bizarre, je croyais avoir compris que l'affichage des messages
était laissé à l'entière discrétion de l'implémenteur.
On Mon, 21 Aug 2006 11:55:36 +0200, Alain Gaillard :
Cela étant si j'en crois 1.3.3 et 1.5.2 le compilo *doit* émettre un message dans notre cas.
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Alain Gaillard
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
Dans le cas présent par contre je n'en suis pas certain et si quelqu'un qui connait le standard sur le bout des doigts voulait donner un avis circontancié, ça serait super.
-- Alain
C'est bizarre, je croyais avoir compris que l'affichage des messages
était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
Dans le cas présent par contre je n'en suis pas certain et si quelqu'un
qui connait le standard sur le bout des doigts voulait donner un avis
circontancié, ça serait super.
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
Dans le cas présent par contre je n'en suis pas certain et si quelqu'un qui connait le standard sur le bout des doigts voulait donner un avis circontancié, ça serait super.
-- Alain
Gabriel Dos Reis
Alain Gaillard writes:
| | | > La norme ne dit pas qu'il doit refuser de compiler le programme : | > juste émettre un diagnostic. Maintenant, ce qui constitue un diagnostic | > est laissé à l'appréciation de l'implémentation. | | Oui c'est vrai. J'ai manqué de précision. Je n'aurais pas du dire | "rejeter" radicalement effectivement. Cela étant si j'en crois 1.3.3 | et 1.5.2 le compilo *doit* émettre un message dans notre cas. Et alors | après oui, il peut accepter de compiler ou non. | | 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. Comme j'ai dit, ce qui constitue un diagnostic est laissé à la discrétion de l'implémentation. Mais tu as raison sur le fond.
|
|
| > La norme ne dit pas qu'il doit refuser de compiler le programme :
| > juste émettre un diagnostic. Maintenant, ce qui constitue un diagnostic
| > est laissé à l'appréciation de l'implémentation.
|
| Oui c'est vrai. J'ai manqué de précision. Je n'aurais pas du dire
| "rejeter" radicalement effectivement. Cela étant si j'en crois 1.3.3
| et 1.5.2 le compilo *doit* émettre un message dans notre cas. Et alors
| après oui, il peut accepter de compiler ou non.
|
| 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. Comme j'ai dit, ce qui constitue un diagnostic est laissé à la
discrétion de l'implémentation. Mais tu as raison sur le fond.
| | | > La norme ne dit pas qu'il doit refuser de compiler le programme : | > juste émettre un diagnostic. Maintenant, ce qui constitue un diagnostic | > est laissé à l'appréciation de l'implémentation. | | Oui c'est vrai. J'ai manqué de précision. Je n'aurais pas du dire | "rejeter" radicalement effectivement. Cela étant si j'en crois 1.3.3 | et 1.5.2 le compilo *doit* émettre un message dans notre cas. Et alors | après oui, il peut accepter de compiler ou non. | | 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. Comme j'ai dit, ce qui constitue un diagnostic est laissé à la discrétion de l'implémentation. Mais tu as raison sur le fond.
-- Gaby
Loïc Joly
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
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.
-- Loïc
C'est bizarre, je croyais avoir compris que l'affichage des messages
était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
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.
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
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.
-- Loïc
Dominique Vaufreydaz
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.
Notons aussi que le message peut etre present peut-etre si le niveau de warning est augmente ?
Doms.
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.
Notons aussi que le message peut etre present peut-etre si le niveau
de warning est augmente ?
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.
Notons aussi que le message peut etre present peut-etre si le niveau de warning est augmente ?
Doms.
kanze
Loïc Joly wrote:
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
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.
Chaîne vide, je ne sais pas, mais c'est vrai que rien n'impose qu'on puisse distinguer le message d'un message qui apparaît par ailleurs. Strictement parlant, le script :
#! /bin/sh echo '?'
est un compilateur C++ tout à fait conforme, à condition de documenter que '?' est un diagnostique. (Qui pourrait signifie, parmi d'autre chose, un dépassement des limites des ressources. C'est un compilateur qui limite l'utilisation des ressources à un point où même "hello, world" les dépasse.)
Il faut se rappeler aussi qu'une fois la diagnostique émise, le comportement est indéfini. Un compilateur qui reformatte le disque dur chaque fois qu'il y a une erreur dans ton code est aussi conforme. Je crois même qu'il pourrait documenter que le message d'erreur, c'est l'allumage du voyant sur le disque.
Dans la pratique, évidemment, de tels compilateurs ne risquent pas de prendre une partie importante du marché.
-- 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
Loïc Joly wrote:
C'est bizarre, je croyais avoir compris que l'affichage des
messages était laissé à l'entière discrétion de
l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu
d'émèttre un message.
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.
Chaîne vide, je ne sais pas, mais c'est vrai que rien n'impose
qu'on puisse distinguer le message d'un message qui apparaît par
ailleurs. Strictement parlant, le script :
#! /bin/sh
echo '?'
est un compilateur C++ tout à fait conforme, à condition de
documenter que '?' est un diagnostique. (Qui pourrait signifie,
parmi d'autre chose, un dépassement des limites des ressources.
C'est un compilateur qui limite l'utilisation des ressources à
un point où même "hello, world" les dépasse.)
Il faut se rappeler aussi qu'une fois la diagnostique émise, le
comportement est indéfini. Un compilateur qui reformatte le
disque dur chaque fois qu'il y a une erreur dans ton code est
aussi conforme. Je crois même qu'il pourrait documenter que le
message d'erreur, c'est l'allumage du voyant sur le disque.
Dans la pratique, évidemment, de tels compilateurs ne risquent
pas de prendre une partie importante du marché.
--
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
C'est bizarre, je croyais avoir compris que l'affichage des messages était laissé à l'entière discrétion de l'implémenteur.
Il y a bel et bien des cas où le compilateur est tenu d'émèttre un message.
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.
Chaîne vide, je ne sais pas, mais c'est vrai que rien n'impose qu'on puisse distinguer le message d'un message qui apparaît par ailleurs. Strictement parlant, le script :
#! /bin/sh echo '?'
est un compilateur C++ tout à fait conforme, à condition de documenter que '?' est un diagnostique. (Qui pourrait signifie, parmi d'autre chose, un dépassement des limites des ressources. C'est un compilateur qui limite l'utilisation des ressources à un point où même "hello, world" les dépasse.)
Il faut se rappeler aussi qu'une fois la diagnostique émise, le comportement est indéfini. Un compilateur qui reformatte le disque dur chaque fois qu'il y a une erreur dans ton code est aussi conforme. Je crois même qu'il pourrait documenter que le message d'erreur, c'est l'allumage du voyant sur le disque.
Dans la pratique, évidemment, de tels compilateurs ne risquent pas de prendre une partie importante du marché.
-- 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
Dominique Vaufreydaz
Bonjour,
Chaîne vide, je ne sais pas, mais c'est vrai que rien n'impose qu'on puisse distinguer le message d'un message qui apparaît par ailleurs. Strictement parlant, le script :
#! /bin/sh echo '?'
Donc vertain message "francisé" (j'ai pas dit traduits) du compilo de visual studio sont donc tout a fait dans la norme. Ouf ! Parcequ'il y en a certains qui craignent quand meme (pour essayer de comprendre ce qui ne va pas !).
Doms.
Bonjour,
Chaîne vide, je ne sais pas, mais c'est vrai que rien n'impose
qu'on puisse distinguer le message d'un message qui apparaît par
ailleurs. Strictement parlant, le script :
#! /bin/sh
echo '?'
Donc vertain message "francisé" (j'ai pas dit traduits) du compilo
de visual studio sont donc tout a fait dans la norme. Ouf ! Parcequ'il y
en a certains qui craignent quand meme (pour essayer de comprendre
ce qui ne va pas !).
Chaîne vide, je ne sais pas, mais c'est vrai que rien n'impose qu'on puisse distinguer le message d'un message qui apparaît par ailleurs. Strictement parlant, le script :
#! /bin/sh echo '?'
Donc vertain message "francisé" (j'ai pas dit traduits) du compilo de visual studio sont donc tout a fait dans la norme. Ouf ! Parcequ'il y en a certains qui craignent quand meme (pour essayer de comprendre ce qui ne va pas !).
Doms.
kanze
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.
Pour le compilo de Visual C++, microsoft affirme respecter 98% (de memoire) de la norme.
Mesuré en quelle unité ? Je sais qu'il ne supporte pas export ; où en est-il avec des templates à paramètre de template ou la recherche des noms à deux phases ?
Un petit essai rapide :
#include <iostream> #include <ostream>
typedef int X ;
template < typename T > struct B { typedef T X ; } ;
template< typename T > struct D : B< T > { X x ; } ;
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.
Notons aussi que le message peut etre present peut-etre si le niveau de warning est augmente ?
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 l'approche de g++, « g++ -std=c++98 ». Mais même alors, je crois que d'autres options pourrait défaire une partie des effets, et éloigner le compilateur de la norme.)
-- 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
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.
Pour le compilo de Visual C++, microsoft affirme respecter 98%
(de memoire) de la norme.
Mesuré en quelle unité ? Je sais qu'il ne supporte pas
export ; où en est-il avec des templates à paramètre de
template ou la recherche des noms à deux phases ?
Un petit essai rapide :
#include <iostream>
#include <ostream>
typedef int X ;
template < typename T >
struct B
{
typedef T X ;
} ;
template< typename T >
struct D : B< T >
{
X x ;
} ;
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.
Notons aussi que le message peut etre present peut-etre si le niveau
de warning est augmente ?
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
l'approche de g++, « g++ -std=c++98 ». Mais même alors, je
crois que d'autres options pourrait défaire une partie des
effets, et éloigner le compilateur de la norme.)
--
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.
Pour le compilo de Visual C++, microsoft affirme respecter 98% (de memoire) de la norme.
Mesuré en quelle unité ? Je sais qu'il ne supporte pas export ; où en est-il avec des templates à paramètre de template ou la recherche des noms à deux phases ?
Un petit essai rapide :
#include <iostream> #include <ostream>
typedef int X ;
template < typename T > struct B { typedef T X ; } ;
template< typename T > struct D : B< T > { X x ; } ;
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.
Notons aussi que le message peut etre present peut-etre si le niveau de warning est augmente ?
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 l'approche de g++, « g++ -std=c++98 ». Mais même alors, je crois que d'autres options pourrait défaire une partie des effets, et éloigner le compilateur de la norme.)
-- 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
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. Comeau et Intel, modulo erreurs.
Faut vraiment que je me paye le compilo Intel (qui s'utilise avec l'IDE Visual...).
Mesuré en quelle unité ? Je sais qu'il ne supporte pas
Aucune idée. C'est juste plus que la precedente version ;-P J'ai bien dit qu'ils annoncent !
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
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. Tiens, j'ai pas trouvé dans l'IDE le moyen d'activier (hors options mise a la main), /vmg.
l'approche de g++, « g++ -std=c++98 ». Mais même alors, je crois que d'autres options pourrait défaire une partie des effets, et éloigner le compilateur de la norme.)
Notons que dans ce cas la, le compilo devrait dire que les options sont incompatibles...
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.
Comeau et Intel, modulo erreurs.
Faut vraiment que je me paye le compilo Intel (qui s'utilise avec l'IDE Visual...).
Mesuré en quelle unité ? Je sais qu'il ne supporte pas
Aucune idée. C'est juste plus que la precedente version ;-P
J'ai bien dit qu'ils annoncent !
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
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. Tiens, j'ai pas trouvé dans l'IDE le
moyen d'activier (hors options mise a la main), /vmg.
l'approche de g++, « g++ -std=c++98 ». Mais même alors, je
crois que d'autres options pourrait défaire une partie des
effets, et éloigner le compilateur de la norme.)
Notons que dans ce cas la, le compilo devrait dire que
les options sont incompatibles...
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.
Faut vraiment que je me paye le compilo Intel (qui s'utilise avec l'IDE Visual...).
Mesuré en quelle unité ? Je sais qu'il ne supporte pas
Aucune idée. C'est juste plus que la precedente version ;-P J'ai bien dit qu'ils annoncent !
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
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. Tiens, j'ai pas trouvé dans l'IDE le moyen d'activier (hors options mise a la main), /vmg.
l'approche de g++, « g++ -std=c++98 ». Mais même alors, je crois que d'autres options pourrait défaire une partie des effets, et éloigner le compilateur de la norme.)
Notons que dans ce cas la, le compilo devrait dire que les options sont incompatibles...
