"Patrick Philippot" a écrit dans le message de news:3f8449f9$0$13272$
Franck Guillaud wrote: > Patrick Philippot wrote: > Certes, mais le temps au bout duquel Microsoft décidera de laisser > tomber le produit sera lui beaucoup moins long ;-)
Ça désolé mais ça ne s'est pas encore produit :-) J'ai des TPs développés pour mes cours MFC / Visual C++ 1.0 en 93 qui marchent encore sous VC++ 6.
C'est parce que tu n'as pas utilisé le mécanisme antidéluvien des exceptions MFC des premières versions....
Je n'ai pas connaissance de produits de développement abandonnés brutalement par MS.
Visual C++ For Macintosh...
David
"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message de news:3f8449f9$0$13272$626a54ce@news.free.fr...
Franck Guillaud wrote:
> Patrick Philippot wrote:
> Certes, mais le temps au bout duquel Microsoft décidera de laisser
> tomber le produit sera lui beaucoup moins long ;-)
Ça désolé mais ça ne s'est pas encore produit :-) J'ai des TPs
développés pour mes cours MFC / Visual C++ 1.0 en 93 qui marchent encore
sous VC++ 6.
C'est parce que tu n'as pas utilisé le mécanisme antidéluvien des exceptions MFC des premières
versions....
Je n'ai pas connaissance de produits de développement
abandonnés brutalement par MS.
"Patrick Philippot" a écrit dans le message de news:3f8449f9$0$13272$
Franck Guillaud wrote: > Patrick Philippot wrote: > Certes, mais le temps au bout duquel Microsoft décidera de laisser > tomber le produit sera lui beaucoup moins long ;-)
Ça désolé mais ça ne s'est pas encore produit :-) J'ai des TPs développés pour mes cours MFC / Visual C++ 1.0 en 93 qui marchent encore sous VC++ 6.
C'est parce que tu n'as pas utilisé le mécanisme antidéluvien des exceptions MFC des premières versions....
Je n'ai pas connaissance de produits de développement abandonnés brutalement par MS.
Visual C++ For Macintosh...
David
Franck Guillaud
Patrick Philippot wrote:
Franck Guillaud wrote:
Patrick Philippot wrote: Certes, mais le temps au bout duquel Microsoft décidera de laisser tomber le produit sera lui beaucoup moins long ;-)
Ça désolé mais ça ne s'est pas encore produit :-) J'ai des TPs développés pour mes cours MFC / Visual C++ 1.0 en 93 qui marchent encore sous VC++ 6.
Bien: et tu arrives à générer du code 16bits pour plateforme win 3.11 ? :-)
Oui, je sais, c'est un peu exagéré mais j'ai eu à affronter le cas il y a quelques années : Microsoft ne supportant plus la version 1.52c de son compilo, il s'est avéré très difficile de mettre à niveau une application existante pour un client, qui évoluait encore sous windows 3.11.
Au final, on a attendu que le client migre :-)
Franck.
Patrick Philippot wrote:
Franck Guillaud wrote:
Patrick Philippot wrote:
Certes, mais le temps au bout duquel Microsoft décidera de laisser
tomber le produit sera lui beaucoup moins long ;-)
Ça désolé mais ça ne s'est pas encore produit :-) J'ai des TPs
développés pour mes cours MFC / Visual C++ 1.0 en 93 qui marchent
encore sous VC++ 6.
Bien: et tu arrives à générer du code 16bits pour plateforme win 3.11 ? :-)
Oui, je sais, c'est un peu exagéré mais j'ai eu à affronter le cas il y a
quelques
années : Microsoft ne supportant plus la version 1.52c de son compilo, il
s'est
avéré très difficile de mettre à niveau une application existante pour un
client,
qui évoluait encore sous windows 3.11.
Patrick Philippot wrote: Certes, mais le temps au bout duquel Microsoft décidera de laisser tomber le produit sera lui beaucoup moins long ;-)
Ça désolé mais ça ne s'est pas encore produit :-) J'ai des TPs développés pour mes cours MFC / Visual C++ 1.0 en 93 qui marchent encore sous VC++ 6.
Bien: et tu arrives à générer du code 16bits pour plateforme win 3.11 ? :-)
Oui, je sais, c'est un peu exagéré mais j'ai eu à affronter le cas il y a quelques années : Microsoft ne supportant plus la version 1.52c de son compilo, il s'est avéré très difficile de mettre à niveau une application existante pour un client, qui évoluait encore sous windows 3.11.
Au final, on a attendu que le client migre :-)
Franck.
Quentin Pouplard
Marre du spam wrote:
"Quentin Pouplard" a écrit dans le message de news: > > > Marre du spam wrote: > > Le fait est que VC6 répond a pratiquement tous les besoins des > > développeurs ayant deja de gros package de code entre leur main. > > Les améliorations de l'IDE .Net sur ce point (pour les > > développeurs d'applications C++ natives) sont plutôt minimes : Le > > compilateur reste non conforme aux standards, > > Tu as des points particulier qui t'ont posé problème dans la > pratique? > j'ai lu quelques cas théorique, mais j'avais toujours du mal à > imaginer des cas réel ou le problème pouvait se poser... tu peux me > faire de ton expérience? for (int i=0;i<MAX;i++) { printf("i = %dn",i); }
printf("i = %dn",i);
Ce bout de code compile sous VC++ alors qu'il est non conforme : i est local à la boucle for.
Il y'a un flag pour ça... ceci dit, c'est du C là, pas vraiment du C++... la conformité des compilos se discutent généralement quand ça devient complexe, avec des templates partielles, des opérateurs surchargés, etc...
> > ne génére pas de code pour les > > derniers processeurs, > > les intrinsics, et la génération de SSE2 c pas assez récent? ;) Itanium, PocketPC restent dans des environnement externes.
Ce ne sont pas "les derniers" processeurs, mais d'autre processeur... dire qu'un compilo est mauvais parce qu'il ne permet pas de compiler pour une plate-forme X est amha un peu boiteux...
Trop de fenêtres à mon gout, des raccourcis claviers qui changent (déjà le 3eme changement pour le Find In Find en 4 versions, ca fait lourd),
Evidemment si tu sais pas configurer ton IDE ;)
des inconsistences d'interface (Menu File -> Open -> File !!!)
boarf... là j'avoue que tu vas trop loin pour moi, ils devaient faire quoi? - ne pas appeler le premier menu en haut à guache "file" -> inconsistance avec les autres applications. - taper des opérations sur les fichiers ailleurs? -> inconsistance avec le nom "file". - ...?
Ceci dit, on est d'accord sur un point VS.NET n'est pas parfait, et si tu as testé mieux, hésite pas à me soumettre ton avis, je rêve toujours de l'ide idéal... pour l'instant ce qui s'en rapprocherait le plus serait un mélange de VS.NET et d'eclipse.
"Quentin Pouplard" <poubelle@alrj.org> a écrit dans le message de
news:281_2003_15284_2012358307_MYOE@news.free.fr...
>
>
> Marre du spam wrote:
> > Le fait est que VC6 répond a pratiquement tous les besoins des
> > développeurs ayant deja de gros package de code entre leur main.
> > Les améliorations de l'IDE .Net sur ce point (pour les
> > développeurs d'applications C++ natives) sont plutôt minimes : Le
> > compilateur reste non conforme aux standards,
>
> Tu as des points particulier qui t'ont posé problème dans la
> pratique?
> j'ai lu quelques cas théorique, mais j'avais toujours du mal à
> imaginer des cas réel ou le problème pouvait se poser... tu peux me
> faire de ton expérience?
for (int i=0;i<MAX;i++)
{
printf("i = %dn",i);
}
printf("i = %dn",i);
Ce bout de code compile sous VC++ alors qu'il est non conforme : i
est local à la boucle for.
Il y'a un flag pour ça... ceci dit, c'est du C là, pas vraiment du
C++... la conformité des compilos se discutent généralement quand ça
devient complexe, avec des templates partielles, des opérateurs
surchargés, etc...
> > ne génére pas de code pour les
> > derniers processeurs,
>
> les intrinsics, et la génération de SSE2 c pas assez récent? ;)
Itanium, PocketPC restent dans des environnement externes.
Ce ne sont pas "les derniers" processeurs, mais d'autre processeur...
dire qu'un compilo est mauvais parce qu'il ne permet pas de compiler
pour une plate-forme X est amha un peu boiteux...
Trop de fenêtres à mon gout, des raccourcis claviers qui changent
(déjà le 3eme changement pour le Find In Find en 4 versions, ca fait
lourd),
Evidemment si tu sais pas configurer ton IDE ;)
des inconsistences d'interface (Menu File -> Open -> File
!!!)
boarf... là j'avoue que tu vas trop loin pour moi, ils devaient faire
quoi?
- ne pas appeler le premier menu en haut à guache "file" ->
inconsistance avec les autres applications.
- taper des opérations sur les fichiers ailleurs? -> inconsistance avec
le nom "file".
- ...?
Ceci dit, on est d'accord sur un point VS.NET n'est pas parfait, et si
tu as testé mieux, hésite pas à me soumettre ton avis, je rêve toujours
de l'ide idéal... pour l'instant ce qui s'en rapprocherait le plus
serait un mélange de VS.NET et d'eclipse.
"Quentin Pouplard" a écrit dans le message de news: > > > Marre du spam wrote: > > Le fait est que VC6 répond a pratiquement tous les besoins des > > développeurs ayant deja de gros package de code entre leur main. > > Les améliorations de l'IDE .Net sur ce point (pour les > > développeurs d'applications C++ natives) sont plutôt minimes : Le > > compilateur reste non conforme aux standards, > > Tu as des points particulier qui t'ont posé problème dans la > pratique? > j'ai lu quelques cas théorique, mais j'avais toujours du mal à > imaginer des cas réel ou le problème pouvait se poser... tu peux me > faire de ton expérience? for (int i=0;i<MAX;i++) { printf("i = %dn",i); }
printf("i = %dn",i);
Ce bout de code compile sous VC++ alors qu'il est non conforme : i est local à la boucle for.
Il y'a un flag pour ça... ceci dit, c'est du C là, pas vraiment du C++... la conformité des compilos se discutent généralement quand ça devient complexe, avec des templates partielles, des opérateurs surchargés, etc...
> > ne génére pas de code pour les > > derniers processeurs, > > les intrinsics, et la génération de SSE2 c pas assez récent? ;) Itanium, PocketPC restent dans des environnement externes.
Ce ne sont pas "les derniers" processeurs, mais d'autre processeur... dire qu'un compilo est mauvais parce qu'il ne permet pas de compiler pour une plate-forme X est amha un peu boiteux...
Trop de fenêtres à mon gout, des raccourcis claviers qui changent (déjà le 3eme changement pour le Find In Find en 4 versions, ca fait lourd),
Evidemment si tu sais pas configurer ton IDE ;)
des inconsistences d'interface (Menu File -> Open -> File !!!)
boarf... là j'avoue que tu vas trop loin pour moi, ils devaient faire quoi? - ne pas appeler le premier menu en haut à guache "file" -> inconsistance avec les autres applications. - taper des opérations sur les fichiers ailleurs? -> inconsistance avec le nom "file". - ...?
Ceci dit, on est d'accord sur un point VS.NET n'est pas parfait, et si tu as testé mieux, hésite pas à me soumettre ton avis, je rêve toujours de l'ide idéal... pour l'instant ce qui s'en rapprocherait le plus serait un mélange de VS.NET et d'eclipse.
Ce bout de code compile sous VC++ alors qu'il est non conforme : i est
local à la boucle for.
la conformité comme les besoins changent au cours du temps. pour justifier de l'utilité d'une telle possibilité, un C-man aurait même inseré un if et un break dans le for.
#define MAX 25 ;
double v[MAX] = ... ;
for(int i=0;i<MAX;i++) if(v[i]>0) break ;
printf("i = %dn",i);
pour ma part, j'ai toujours critiqué amerement VC6 sur de nombreux points. ça, c'est une poussiere dans l'univers. en écrivant ce qui suit, on ne sacrifie rien, et on met en évidence l'inutilité flagrande du concept.
int findfirstpositive(const double *v,const int count) { for(int i=0;i<count;i++) if(v[i]>0.) return i ; return count ; // ou -1, comme on veux. }
void test() { const int count = 25 ;
const double *v = ...
const int i = findfirstpositive(v,count) ;
cout << "i = " << i << endl ; }
j'entends déja la suite logique : "oh mais on a écrit une fonction en plus, dans un contexte temps réel, vous ne vous rendez pas compte, et puis si on change la regle de portée, va falloir modifier tout notre code blablabla baratin dramatisation faux arguments justifications contradictioires et menaces d'acheter chez Borland". :) alors qu'en fait, en sémantique, en conformance de type, en qualité, en pouvoir d'expression, et en reutilisation, on y a largement gagné. ça aurait été encore mieux avec de la stl.
si les developpeurs écrivaient du C++ et un peu moins de C, eh ben on en serait pas à subir un tel conservatisme destiné à assurer une perenité à leur existant. enfin bon, c'est juste mon avi.
Trop de fenêtres à mon gout, des raccourcis claviers qui changent (déjà le
3eme changement
pour le Find In Find en 4 versions, ca fait lourd), des inconsistences
d'interface (Menu File -> Open -> File !!!)
si y a que ça...
> for(int i=0;i<MAX;i++)
printf("i = %dn",i);
printf("i = %dn",i);
Ce bout de code compile sous VC++ alors qu'il est non conforme : i est
local à la boucle for.
la conformité comme les besoins changent au cours du temps.
pour justifier de l'utilité d'une telle possibilité, un C-man aurait même
inseré un if et un break dans le for.
#define MAX 25 ;
double v[MAX] = ... ;
for(int i=0;i<MAX;i++)
if(v[i]>0)
break ;
printf("i = %dn",i);
pour ma part, j'ai toujours critiqué amerement VC6 sur de nombreux points.
ça, c'est une poussiere dans l'univers.
en écrivant ce qui suit, on ne sacrifie rien, et on met en évidence
l'inutilité flagrande du concept.
int findfirstpositive(const double *v,const int count)
{
for(int i=0;i<count;i++)
if(v[i]>0.)
return i ;
return count ; // ou -1, comme on veux.
}
void test()
{
const int count = 25 ;
const double *v = ...
const int i = findfirstpositive(v,count) ;
cout << "i = " << i << endl ;
}
j'entends déja la suite logique : "oh mais on a écrit une fonction en plus,
dans un contexte temps réel, vous ne vous rendez pas compte, et puis si on
change la regle de portée, va falloir modifier tout notre code blablabla
baratin dramatisation faux arguments justifications contradictioires et
menaces d'acheter chez Borland". :)
alors qu'en fait, en sémantique, en conformance de type, en qualité, en
pouvoir d'expression, et en reutilisation, on y a largement gagné. ça aurait
été encore mieux avec de la stl.
si les developpeurs écrivaient du C++ et un peu moins de C, eh ben on en
serait pas à subir un tel conservatisme destiné à assurer une perenité à
leur existant.
enfin bon, c'est juste mon avi.
Trop de fenêtres à mon gout, des raccourcis claviers qui changent (déjà le
3eme changement
pour le Find In Find en 4 versions, ca fait lourd), des inconsistences
Ce bout de code compile sous VC++ alors qu'il est non conforme : i est
local à la boucle for.
la conformité comme les besoins changent au cours du temps. pour justifier de l'utilité d'une telle possibilité, un C-man aurait même inseré un if et un break dans le for.
#define MAX 25 ;
double v[MAX] = ... ;
for(int i=0;i<MAX;i++) if(v[i]>0) break ;
printf("i = %dn",i);
pour ma part, j'ai toujours critiqué amerement VC6 sur de nombreux points. ça, c'est une poussiere dans l'univers. en écrivant ce qui suit, on ne sacrifie rien, et on met en évidence l'inutilité flagrande du concept.
int findfirstpositive(const double *v,const int count) { for(int i=0;i<count;i++) if(v[i]>0.) return i ; return count ; // ou -1, comme on veux. }
void test() { const int count = 25 ;
const double *v = ...
const int i = findfirstpositive(v,count) ;
cout << "i = " << i << endl ; }
j'entends déja la suite logique : "oh mais on a écrit une fonction en plus, dans un contexte temps réel, vous ne vous rendez pas compte, et puis si on change la regle de portée, va falloir modifier tout notre code blablabla baratin dramatisation faux arguments justifications contradictioires et menaces d'acheter chez Borland". :) alors qu'en fait, en sémantique, en conformance de type, en qualité, en pouvoir d'expression, et en reutilisation, on y a largement gagné. ça aurait été encore mieux avec de la stl.
si les developpeurs écrivaient du C++ et un peu moins de C, eh ben on en serait pas à subir un tel conservatisme destiné à assurer une perenité à leur existant. enfin bon, c'est juste mon avi.
Trop de fenêtres à mon gout, des raccourcis claviers qui changent (déjà le
3eme changement
pour le Find In Find en 4 versions, ca fait lourd), des inconsistences
d'interface (Menu File -> Open -> File !!!)
si y a que ça...
Remi Thomas
David Scrève wrote:
"Arnaud Debaene" a écrit dans le message de news:3f848137$0$20172$
David Scrève wrote:
Le compilateur reste non conforme aux standards
Tous les experts considèrent pourtant qu'ill n'y a guère que Comeau qui soit meilleur aujourd'hui.
A mon avis, CodeWarrior est bien plus abouti que VC++, en tant que compilateur Il est beaucoup plus strict. Je n'ai pas testé le compilateur Intel.
David
Attention ceci était vrai pour Visual C++ 6.0 voir Visual C++ 2002. Par contre ce n'est plus du tout exacte pour Visual C++ 2003. Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque) Visual C++ 2002 c'est 87.63% Visual C++ 2003 c'est 98.11% Cette dernier version fonctionne par exemple avec les bibliothèques Boost et Loki
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
David Scrève wrote:
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message
de news:3f848137$0$20172$626a54ce@news.free.fr...
David Scrève wrote:
Le compilateur reste non conforme aux standards
Tous les experts considèrent pourtant qu'ill n'y a guère que Comeau
qui soit
meilleur aujourd'hui.
A mon avis, CodeWarrior est bien plus abouti que VC++, en tant
que compilateur Il est beaucoup plus strict. Je n'ai pas testé le
compilateur Intel.
David
Attention ceci était vrai pour Visual C++ 6.0 voir Visual C++ 2002. Par
contre ce n'est plus du tout exacte pour Visual C++ 2003.
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque)
Visual C++ 2002 c'est 87.63%
Visual C++ 2003 c'est 98.11%
Cette dernier version fonctionne par exemple avec les bibliothèques Boost et
Loki
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
"Arnaud Debaene" a écrit dans le message de news:3f848137$0$20172$
David Scrève wrote:
Le compilateur reste non conforme aux standards
Tous les experts considèrent pourtant qu'ill n'y a guère que Comeau qui soit meilleur aujourd'hui.
A mon avis, CodeWarrior est bien plus abouti que VC++, en tant que compilateur Il est beaucoup plus strict. Je n'ai pas testé le compilateur Intel.
David
Attention ceci était vrai pour Visual C++ 6.0 voir Visual C++ 2002. Par contre ce n'est plus du tout exacte pour Visual C++ 2003. Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque) Visual C++ 2002 c'est 87.63% Visual C++ 2003 c'est 98.11% Cette dernier version fonctionne par exemple avec les bibliothèques Boost et Loki
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Franck Guillaud
Remi Thomas wrote:
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque) Visual C++ 2002 c'est 87.63% Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Franck.
Cette dernier version fonctionne par exemple avec les bibliothèques Boost et Loki
Rémi
Remi Thomas wrote:
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de
l'époque) Visual C++ 2002 c'est 87.63%
Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Franck.
Cette dernier version fonctionne par exemple avec les bibliothèques
Boost et Loki
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque) Visual C++ 2002 c'est 87.63% Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Franck.
Cette dernier version fonctionne par exemple avec les bibliothèques Boost et Loki
Rémi
adebaene
"Franck Guillaud" wrote in message news:<bm3soi$8b2$...
Remi Thomas wrote: > > Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de > l'époque) Visual C++ 2002 c'est 87.63% > Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Je n'arrive pas à remettre la main sur la source "offcielle" de ces chiffres, mais si tu veux le détail de ce qui manque à VC pour être complêtement conforme, c'est : 1) le mot-clé "export". 2) le "dependant name lookup" 3) les spécifications d'exceptions.
Sachant que certain gourous discuttent encore de l'utilité des points 1 et surtout 3...
Arnaud
"Franck Guillaud" <f@nospam.org> wrote in message news:<bm3soi$8b2$1@news2.isdnet.net>...
Remi Thomas wrote:
>
> Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de
> l'époque) Visual C++ 2002 c'est 87.63%
> Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Je n'arrive pas à remettre la main sur la source "offcielle" de ces
chiffres, mais si tu veux le détail de ce qui manque à VC pour être
complêtement conforme, c'est :
1) le mot-clé "export".
2) le "dependant name lookup"
3) les spécifications d'exceptions.
Sachant que certain gourous discuttent encore de l'utilité des points
1 et surtout 3...
"Franck Guillaud" wrote in message news:<bm3soi$8b2$...
Remi Thomas wrote: > > Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de > l'époque) Visual C++ 2002 c'est 87.63% > Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Je n'arrive pas à remettre la main sur la source "offcielle" de ces chiffres, mais si tu veux le détail de ce qui manque à VC pour être complêtement conforme, c'est : 1) le mot-clé "export". 2) le "dependant name lookup" 3) les spécifications d'exceptions.
Sachant que certain gourous discuttent encore de l'utilité des points 1 et surtout 3...
Arnaud
Franck Guillaud
Arnaud Debaene wrote:
"Franck Guillaud" wrote in message news:<bm3soi$8b2$...
Remi Thomas wrote:
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque) Visual C++ 2002 c'est 87.63% Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Je n'arrive pas à remettre la main sur la source "offcielle" de ces chiffres, mais si tu veux le détail de ce qui manque à VC pour être complêtement conforme, c'est : 1) le mot-clé "export". 2) le "dependant name lookup" 3) les spécifications d'exceptions.
Sachant que certain gourous discuttent encore de l'utilité des points 1 et surtout 3...
Le comité de normalisation fournit un série de "conformance tests" ?
On trouve aussi des chiffres de ce genre sur les pages de boost, mais ça, tu dois déjà le savoir.
Ce qui me faisait rire dans le post de Rémi Thomas c'est le conforme à "81.03%" ou "87,63%" qu'il sort de son chapeau comme un lapin de magicien :-)
Franck.
Arnaud
Arnaud Debaene wrote:
"Franck Guillaud" <f@nospam.org> wrote in message
news:<bm3soi$8b2$1@news2.isdnet.net>...
Remi Thomas wrote:
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de
l'époque) Visual C++ 2002 c'est 87.63%
Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Je n'arrive pas à remettre la main sur la source "offcielle" de ces
chiffres, mais si tu veux le détail de ce qui manque à VC pour être
complêtement conforme, c'est :
1) le mot-clé "export".
2) le "dependant name lookup"
3) les spécifications d'exceptions.
Sachant que certain gourous discuttent encore de l'utilité des points
1 et surtout 3...
Le comité de normalisation fournit un série de "conformance tests" ?
On trouve aussi des chiffres de ce genre sur les pages de boost, mais ça,
tu dois déjà le savoir.
Ce qui me faisait rire dans le post de Rémi Thomas c'est le conforme à
"81.03%" ou "87,63%" qu'il sort
de son chapeau comme un lapin de magicien :-)
"Franck Guillaud" wrote in message news:<bm3soi$8b2$...
Remi Thomas wrote:
Visual C++ 6.0 était à 81.03% conforme à la norme ISO C++ (de l'époque) Visual C++ 2002 c'est 87.63% Visual C++ 2003 c'est 98.11%
Trop fort les pourcentages !!! Ca sort d'où ?
Et puis surtout, ça veut dire quoi ?
Je n'arrive pas à remettre la main sur la source "offcielle" de ces chiffres, mais si tu veux le détail de ce qui manque à VC pour être complêtement conforme, c'est : 1) le mot-clé "export". 2) le "dependant name lookup" 3) les spécifications d'exceptions.
Sachant que certain gourous discuttent encore de l'utilité des points 1 et surtout 3...
Le comité de normalisation fournit un série de "conformance tests" ?
On trouve aussi des chiffres de ce genre sur les pages de boost, mais ça, tu dois déjà le savoir.
Ce qui me faisait rire dans le post de Rémi Thomas c'est le conforme à "81.03%" ou "87,63%" qu'il sort de son chapeau comme un lapin de magicien :-)
Franck.
Arnaud
Remi Thomas
> Ce qui me faisait rire dans le post de Rémi Thomas c'est le conforme à "81.03%" ou "87,63%" qu'il sort de son chapeau comme un lapin de magicien :-)
Non je ne suis pas magicien. J'ai obtenu ces poucentages au TechEd 2003 sur une session sur C++. Après comment ils sont calculés je ne sais pas. Ce que je sais c'est que l'équipe de développement du compilateur C++ est très à cheval sur la conformité ISO de leur produit. Si tu consultes sur Google les archives du forum microsoft.public.dotnet.languages.vc tu verra que les chefs de projets Microsoft participent et creuse chaque non conformité qui est remontée. C'est nouveau, il vas falloir s'y habituer.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
> Ce qui me faisait rire dans le post de Rémi Thomas c'est le conforme
à "81.03%" ou "87,63%" qu'il sort
de son chapeau comme un lapin de magicien :-)
Non je ne suis pas magicien. J'ai obtenu ces poucentages au TechEd 2003 sur
une session sur C++.
Après comment ils sont calculés je ne sais pas.
Ce que je sais c'est que l'équipe de développement du compilateur C++ est
très à cheval sur la conformité ISO de leur produit.
Si tu consultes sur Google les archives du forum
microsoft.public.dotnet.languages.vc tu verra que les chefs de projets
Microsoft participent et creuse chaque non conformité qui est remontée.
C'est nouveau, il vas falloir s'y habituer.
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
> Ce qui me faisait rire dans le post de Rémi Thomas c'est le conforme à "81.03%" ou "87,63%" qu'il sort de son chapeau comme un lapin de magicien :-)
Non je ne suis pas magicien. J'ai obtenu ces poucentages au TechEd 2003 sur une session sur C++. Après comment ils sont calculés je ne sais pas. Ce que je sais c'est que l'équipe de développement du compilateur C++ est très à cheval sur la conformité ISO de leur produit. Si tu consultes sur Google les archives du forum microsoft.public.dotnet.languages.vc tu verra que les chefs de projets Microsoft participent et creuse chaque non conformité qui est remontée. C'est nouveau, il vas falloir s'y habituer.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
David Scrève
"Quentin Pouplard" a écrit dans le message de news:
> for (int i=0;i<MAX;i++) > { > printf("i = %dn",i); > } > > printf("i = %dn",i); > > Ce bout de code compile sous VC++ alors qu'il est non conforme : i > est local à la boucle for.
Il y'a un flag pour ça... ceci dit, c'est du C là, pas vraiment du C++...
Non, c'est du C++. Essaye de compiler ca avec un compilo C, et tu verras...
David
"Quentin Pouplard" <poubelle@alrj.org> a écrit dans le message de news:282_2003_121631_1537828862_MYOE@news.free.fr...
> for (int i=0;i<MAX;i++)
> {
> printf("i = %dn",i);
> }
>
> printf("i = %dn",i);
>
> Ce bout de code compile sous VC++ alors qu'il est non conforme : i
> est local à la boucle for.
Il y'a un flag pour ça... ceci dit, c'est du C là, pas vraiment du
C++...
Non, c'est du C++. Essaye de compiler ca avec un compilo C, et tu verras...
"Quentin Pouplard" a écrit dans le message de news:
> for (int i=0;i<MAX;i++) > { > printf("i = %dn",i); > } > > printf("i = %dn",i); > > Ce bout de code compile sous VC++ alors qu'il est non conforme : i > est local à la boucle for.
Il y'a un flag pour ça... ceci dit, c'est du C là, pas vraiment du C++...
Non, c'est du C++. Essaye de compiler ca avec un compilo C, et tu verras...