J´ai lu sur un newsgroup que VC++ 6.0 était buggé à ce niveau là . . ( le fait de ne pas autoriser l´init dans le header, ce point faisant partie apparemment de la norme).

Pour moi le fait de déclarer la constante dans le cpp restreint la portée à ce même cpp ce qui en fait en quelque sorte une variable statique ( en tant que constante).

L´affectation " test = . .." ne fait peut être pas le contrôle du type ( les constantes étant vérifiées lors de la compilation), mais le case lui implique une vérification des valeurs qui doivent être des const . ..

^^^oui, fortement possible
jusqu´à présent j´ai toujours utilisé mes static const en version . h/.cpp ( merci le 6.0 pour cette mauvaise habitude ; ) ) mais je vais désormais faire l´init dans le . h, maintenant que c´est possible !

merci pour le temps passé à décortiquer ce problème.

avec plaisir ca m´aura appris également une nouvelle faiblesse de la 6.0

Ca y est, j´ai jeter un coups d´oeuil a C++ . NET.
Et je dois avouer que je l´aime pas du tout.

" pour moi le standard c´est le c++ ansi ISO/IEC FDIS 14882:1998(E)"

"on a beau utiliser VC . NET on fait quand meme du C++ normal "

Il faudrait renommer le sujet " [C++.NET] static const". Car le C++ . NET n´a plus grand chose avec le C++ standard, mis a par la syntaxe.

" Il faudrait renommer le sujet"

mais *NON* justement, on parle de C++ normal, pas de C++ . NET ou de manageed C++.
L´IDE s´appelle . NET, il supporte le framework du meme nom, tant mieux, mais ça nous empeche pas de continuer à compiler du C++ traditionnel.

" Car le C++ . NET n´a plus grand chose avec le C++ standard, mis a par la syntaxe"

ah et que tu trouves de si différent avec le C++ " standard" ?

ben je pense qu´il parle de managed C++ en disant C++ . NET, du coup c´est sûr que pas mal de chose changent : plus d´héritage multiple, nouveaux mots clefs, gestion de la stack du CLR, etc.

Oui ca doit etre ca, mais c´est bizarre tout de meme:

sous vc on pouvait(peut?) pas initialiser un const d´une classe dans le . h ( c´est nul, non?) ( on peut tout de meme utiliser un enum d´apres
support.microsoft.com/default.aspx?scid=kb;EN-US;2
41569), mais dans le . cpp.
Si cette constante non initialisee dans le . h, je veux bien etre d accord avec vc qui merde lorsqu on veut l´utiliser dans un autre . cpp que celui ou elle est definie. Quoique.. si il ne permet pas de l initialiser, ne devrait-t´il pas la considerer comme un extern? Et pkoi ca plante si on l´utilise dans le meme . cpp que l´initialisation?

Quelle " merde" vc, pas fichu d etre iso compliant ; )

"L´IDE s´appelle . NET, il supporte le framework du meme nom, tant mieux, mais ça nous empeche pas de continuer à compiler du C++ traditionnel."

Je te met au defit de compiler un prog . NET de monsieur X avec un compilateur conforme a la norme. Au premier __gc ou __super c´est louper.

"ah et que tu trouves de si différent avec le C++ " standard" ? "

Garbage colector, nouveau mot de syntaxe pure . NET, la super habitude a prendre d´implementer les classe dans le . h

"ben je pense qu´il parle de managed C++ en disant C++ . NET"

Crois tu vraiment qu´il y ai, suivant les options , 2 methodes de compilation dans VC++.NET.

Tu pourras peut etre inclure du code C++ ISO, sans compter les templates bien sur, mais de la a utiliser du code . NET dans un projet C++ ISO... Faut faire attention.

eh eh, oui, mais qu´est-ce que l´IDE est pratique :D

pour vc6 en tout cas, les static const sur membre de classe étaient considérés comme des " extern", mes bouts de codes marchaient tres bien...

Je viens de penser a quelques chose la . ...
pour quoi utiliser vous . NET ? ?
Si c´est pas pour, au minimum faire des interfaces grahique je vois pas le truc...

" jusqu´à présent j´ai toujours utilisé mes static const en version . h/.cpp ( merci le 6.0 pour cette mauvaise habitude ; ) ) mais je vais désormais faire l´init dans le . h, maintenant que c´est possible ! "

. .. Faut plutot dire merci norme ISO... j´espere que tu n´aura jamais a faire ailleur que sur . NET sinon faudra réapprendre.

on utilise . NET parceque l´IDE offre des fonctionnalités interessantes, et qu´il y a qq outils forts sympathiques qui s´y intègrent on ne peut mieux ( => versionning entre autres). Donc c´est plus niveau confort d´env. de dev. Enfin, en ce qui me concerne, et je pense que c´est pour bcp pareil.

" j´espere que tu n´aura jamais a faire ailleur que sur . NET sinon faudra réapprendre."

ben disons que j´adapte mon code au compilo ; quand j´avais à utiliser gcc, l´initialisation des static const était conforme, donc je l´utilisais. Quand j´utilisais le c++ compiler de intel, certains choses concernant les templates étaient supportées alors que sous VC non ; donc au final, ben je fais du code pour que ça compile en fonction de ce que le compilo supporte, et dès on tombe sur un truc qu´on pense supporté mais qui ne l´est pas ( comme dans le post initial de ce thread)

" pour quoi utiliser vous . NET ? "

Parcqu´on me le demande au boulot, ou plutôt nos clients nous le demandent et oui faut bien faire vivre la boite en suivant la demande du marché et justifier son salaire à la fin du mois ; ) Et contrairement à ce que tu crois . NET permet bien d´autres choses que faire des interfaces : notament tout ce qui concerne les applis pour le web... mais là on s´éloigne du C++, mais sinon une amélioration de l´IDE non négligeable.

" Garbage colector, nouveau mot de syntaxe pure . NET, la super habitude a prendre d´implementer les classe dans le . h"

ah ok c´est énorme comme différences en effet

" Crois tu vraiment qu´il y ai, suivant les options , 2 methodes de compilation dans VC++.NET."

2 non, plusieurs oui rien que le fait de désactiver les extensions de langage ca en fait déjà 2 et vu le nombre d´options j´imagine que ca peut grimper vite...

" sinon faudra réapprendre"

Enfin bref, mis à part à la fac, jusqu´à présent je n´ai été amené à développer que sur et pour Windows ( sauf 1 fois pour convertir une appli Windows sur Linux) alors je me laisse penser que ces histoires de norme c´est bien loin des réalités . .. ca me fait un peu penser aux différences ( de taille) qu´il existe entre le monde de la recherche et l´industrie ( la pratique quoi). Les " puristes" sont là pour pondre des théories, normaliser leur travaux etc... mais la pratique est bien souvent différente ( bien que normalisée elle aussi) et on arrive donc forcément à des différences.

Alors je dis pas, certains secteurs ont surement besoin d´un respect des normes ISO mais cela reste assez spécifique à mes yeux.

Pour rejoindre LGV, la majorité des boites développant en C++ sur Windows utilisent Visual Studio ( 6.0 ou > ) et l´on s´adapte forcément à ce qui nous est offert. De plus les problèmes de non respect des normes rencontrés sont vraiment très limités et toujours contournables alors pourquoi se prendre la tête

et en fait je ne vois pas vraiment en quoi je devrais réapprendre quoi que ce soit :-?
on est prié d´interpréter *toute* la phrase que tu cites :

( sous entendu sous VC6/NET)
" jusqu´à présent j´ai toujours utilisé mes static const en version . h/.cpp ( merci le 6.0 pour cette mauvaise habitude ; ) ) mais je vais désormais faire l´init dans le . h, *MAINTENANT QUE CE C´EST POSSIBLE* ! "

ce qui veut tres clairement dire, selon moi, que bien évidemment, si le compilo supporte, je fais l´init avec la decl. Mais quand c´est pas supporté, je fais quoi ? je réécris le parser de source ? . ..
c´est en rencontrant tous ces soucis qu´on fini par connaitre un compilateur ; et je me permettrais donc de dire, de manière qq peu symétrique, j´espère que tu n´auras jamais à travailler avec un compiler ne respectant pas la norme, sinon il te faudra tout réapprendre ; )

Alors je dis pas, certains secteurs ont surement besoin d´un respect des normes ISO mais cela reste assez spécifique à mes yeux.

Les jeux videos => portages pour ps2..

" Les jeux videos => portages pour ps2.."

c´est bien ce que je dis, cas bien spécifique

et le portage sur Xbox ? mouarf no comment . ..

sinon pour ceux que ça interesse, on peut toujours faire du Fortran 77... depuis le temps, il doit bien exister des compilos 100% " standard compliant" LOOOOOL ( bon, faut etre motivé quand meme hein)

lol de toute facon je doute fort qu´il existe un seul compilo respectant à 100% la norme . ..

Juste pour info, ca peut toujours intéresser certains :

http://www.cuj.com/roundup/

résultat de tests effectués sur divers compilos pour voir le respect de la norme ISO ( lien fourni sur http://www.research.att.com/~bs/compilers.html )

ah ben tiens, ce lien tombe à point nommé ! Encore hier avec kUfa on cherchait un truc du style, permettant de " quantifier" le degré de respect du standard.

" j´espère que tu n´auras jamais à travailler avec un compiler ne respectant pas la norme, sinon il te faudra tout réapprendre ; )"

Ce sera tout a fait le cas si ma boite se decide a passer a . NET.
Je n´ai rien contre . NET en général, juste contre le C++ . NET. Je trouve pas génial le faite de " s´approprié" un langage ( sa syntaxe et on nom) pour en faire un produit a part et non compatible. Volontairement incompatible qui plus est.

C´etait pour cette raison que je tenais a souligner la difference entre le C++.NET avec ses regles et le C++ ISO.
Il ne faudrait pas qu´un debutant arrive sur ce forum, et essaye d´assigner une valeur a un static dans le . h... Ce serait pas sympa de notre pars.
Garder a l´esprit que pour certaines personne le GCC et VC++.NET sont des compilateurs équivanlent.