J'utilise windows 7 64 bits avec MSVC2005 et QT (mais je doute de l'intervalle QT est à l'origine du problème puisque c'est un problème avec le type de données de base car.weired comportement char en C++/MSVC2005/Windows 7 64 bits
alors, quand j'essaie de comparer deux omble chevalier est comme si
char A=0xAA;
if(A==0xAA)
printf("Success");
else
printf("Fail");
et voici lo il échoue! mais quand je le fais
char A=0xAA;
char B=0xAA;
if(A==B)
printf("Success");
else
printf("Fail");
Je reçois le succès! en fait, quand je pensais à ce sujet ... hey Je travaille o n un processeur 64 bits ... même si les chars sont censés être traités comme 1 octet. Il est probablement stocké en 4 octets. Donc
char A=0xAA;
if(A==0xFFFFFFAA)
printf("Success");
else
printf("Fail");
Maintenant, j'ai du succès !!!
Mais WTF! Est-ce le comportement standard !! Si la foutue chose est définie comme un char, le compilateur ne devrait-il pas savoir quoi en faire? D'autres tests montrent que les octets supplémentaires ne sont stockés que si le bit le plus significatif du char est 1. Si 0x07 et inférieur est stocké comme 0x00000007. WTF.
En fait, j'ai semblé avoir répondu à toutes mes questions ... sauf à qui appeler pour obtenir ce bug corrigé. Est-ce que c'est même un bug? Vous pouvez utiliser MSVC2005 sur des systèmes d'exploitation 64 bits ou suis-je un idiot. Je suppose que je devrais obtenir qt créateur pour utiliser MSVC2010 .. damn it. Voilà mes 2 heures.
+1. Cela n'a rien à voir avec 64 bits. Char est un octet unique sur Windows 32 bits et 64 bits. –
Essayez 'if (A == ((char) 0xAA))' ou 'if (A == '\ xAA')' – Steve314
Je suppose que mon erreur fatale supposait que si je devais prendre la peine de définir une valeur en hexadécimal , le compilateur sait automatiquement que vous voulez assigner la valeur comme non signée. Explosion! – umps