Voici mes fichiers :
 
 

 
 
Ces deux fichiers me génerent un .lib ( libraire statique ) que j'utilise dans un projet. J'ai un probleme dans ce fichier :
 

 
Et la, au linkage, il me sort :
 
error LNK2001: unresolved external symbol "public: static unsigned char const  MyClass::MyConst" (?MyConst@MyClass@@2EB)
 
J'ai été voir dans le fichier .lib, MyConst apparait, mais différement, en effet la décoration n'est pas la meme :
 
error LNK2001: unresolved external symbol "public: static unsigned char const  MyClass::MyConst" (?MyConst@MyClass@@0EB)
 
D'ou vient cette différence?

essayes en initialisant au meme endroit que la déclaration

J'ai déja essayé ... il accepte pas; Il me sort :
 
illegal pure syntax, must be '= 0'
 
Entre nous je trouve ce message d'erreur assez bizarre...

il est joli effectivement (s'emmele avec les fonctions virtuelles pures)

Non, sérieux, c'est normal ce message d'erreur?  
On a bien le droit de déclarer des constantes dans une classe, non?

entières oui

fais un enum plutot

ben du à certains compilo, c'est effectivement une technqiue tout à fait correcte

VC++ roulaize...  
 
EDIT : j'avais dis une connerie. Une grosse.

C'est un bug du compilo. Y'a plusieurs alternatives :

 
ou d'autres :
http://www.boost.org/more/int_const_guidelines.htm

la vraie solution à ce genre de problème, pour des objets plus conséquents, c'est une foncction membre statique qui renvoie une référence et qui a une variable statique. ça donne lsassurance que l'objet est bien construit au moment de l'appel. ta technique ne resout rien et renvoyer une copie c'est maladroit

 
En même temps pour un unsigned car ça prend moin de place sur la pile    
 
Par contre la variable static c pas con.

ben on parle génériquement là... c'est sur que la ref pour un entier, mais bon, le cas const est un sous cas

 
C sur que dans le cas générique on s'orienteras plus vers une référence.

 
J'avais d'abord pensé à écrire directement :

 
 
Mais je pensais que Ace17 voulais garder sa variable membre statique .
En revanche, j'ai du mal à te suivre en ce qui concerne la possibilité de renvoyer un objet non construit.
En quoi une variable statique déclarée à l'intérieur du corps d'une fonction est plus sûre (systématiquement construite avant l'appel) qu'une variable statique déclarée dans une classe ? (pas systématiquement construite ?)
Je vois pas trop aussi pourquoi c'est maladroit de renvoyer une copie de char.

Etant donné que tu va donné ça valeur initiale à ton champ statique dans un fichier CPP, tu n'est pas sur, si tu appelle ta méthode statique dans un autre module, que le membre sera bie ninitialisé avant l'appel.

Bon, je crois que je vais opter pour le enum  

 
Je comprend toujours pas ... je vais t'expliquer comment je pense que cela ça se passe, ccorrige moi :
une variable membre statique est considérée par le compilo de la même manière qu'une variable globale. Elle est placée sur le tas, et initialisée avant même l'appel à main. Dans le cas d'un type simple, sa valeur est directement placée dans l'exe, dans une section "variables initialisées" (.data). Pour les objets, le compilo se charge d'appeler leur constructeur, mais je ne sais pas trop quand. Peut être que c'est là que ça pose problème.
Mais je comprend pas pourquoi en étant une variable statique on est sûr que c'est bien construit, et en étant un attribut de classe statique on ne l'est pas. A moins que ce ne soit la référence qui joue, ce que j'aurais encore + de mal à comprendre.

 
T'as la réponse dans ton text: c initialisé avant le main, mais c pas la seule chose à dnas ce cas là, imagine un truc tout con:
 
A.h

A.cpp

B.h

B.cpp

C lequel qui est initialisé en premier? Ben on sait pas, d'où le PB.

Ben j'aurais dis que le compilo s'y retrouve à l'édition des liens et initialise NumB avec NumA "en dur" dans l'exe.
Le mieux c'est que je vérifie cela avec un test.

 
Avec les types atomique c peut être pas très flagrant, mais ça pose des pb avec les objets, c certain.