C++ enum pour unsigned int comparaison
J'ai trouvé ça dans le code, je travaille en ce moment et pensait que c'était la cause de certains problèmes que je vais avoir.
Dans un en-tête quelque part:
enum SpecificIndexes{
//snip
INVALID_INDEX = -1
};
Puis plus tard - initialisation:
nextIndex = INVALID_INDEX;
et l'utilisation
if(nextIndex != INVALID_INDEX)
{
//do stuff
}
Débogage du code, les valeurs de nextIndex n'a pas tout à fait le faire sence (ils étaient très gros), et j'ai trouvé qu'il a été déclaré:
unsigned int nextIndex;
Donc, le réglage initial pour INVALID_INDEX était underflowing la unsigned int et la valeur d'un grand nombre. J'ai supposé que c'était ce qui était à l'origine du problème, mais en regardant de plus près, le test
if(nextIndex != INVALID_INDEX)
Était de se comporter correctement, j'.e, il n'a jamais exécuté le corps de la si quand nextIndex était le "grand +ve valeur".
Est-ce correct? Comment est-ce arrivé? Est la valeur d'enum être implicitement converti en unsigned int du même type que la variable, et donc d'être enveloppé dans de la même façon?
- ITYM "Puis, plus tard - asssignment". Initialisation serait
unsigned nextIndex = INVALID_INDEX
Vous devez vous connecter pour publier un commentaire.
Oui à tout.
Il est valable de code, il est aussi couramment utilisé bibliothèque côté de code C++, en C++ moderne (c'est étrange quand on la voit la première fois, mais c'est un schéma très commun dans la réalité).
Puis les énumérations sont signés ints, mais ils se implicitement converti en unsigned ints, maintenant, ce en fonction de votre compilateur peut donner un avertissement, mais sa reste très couramment utilisée, mais vous devez explicitement exprimées à faire comprendre aux responsables de la maintenance.
les énumérations peuvent être représentés par un signés ou non partie intégrante types, selon qu'ils contiennent des valeurs négatives et que le compilateur se sent comme. L'exemple contient une valeur négative et doit donc être représenté par un signé de type intégral.
Comparaison d'égalité entre les entiers signés et non signés est sûr et n'est généralement ce que l'auteur veut - la valeur signée seront convertis en unsigned premier, et le résultat de cela est défini par la norme C++ et est intuitive (au moins, c'est une fois que vous connaissez le type de destination. Sauf peut-être si les entiers ne sont pas en complément à deux. Donc peut-être pas intuitif, mais il n'est normalement pas causer des problèmes).
Comparaison de l'ordre est plus susceptible d'entraîner des erreurs. Par exemple:
retourne false, mais:
renvoie la valeur true. Parfois, l'auteur ne va pas apprécier la différence, surtout si le type de la "valeur" n'est pas tout à fait aussi évident au point d'utilisation. Le compilateur peut bien avertir le deuxième exemple, bien que, en raison de la valeur (>= 0) est une tautologie.
En fait, -1 est implicitement convertie en son equivalente non signé valeur lorsqu'elle est attribuée à nextValue. Le equivalente non signé est la valeur avec le même bit à bit de la représentation (qui est 111111111111..., c'est, le maximum de valeur non signée).
Plus tard, dans la comparaison de la déclaration, l'autre implicite de fonte qui se passe.
Donc ce qui fonctionne en ce moment, mais peut causer de problème à l'avenir. Ce n'est jamais une bonne idée de mélanger signés et non signés valeurs.
Oui, je crois que les énumérations sont signés. Changement
à
et votre programme devrait fonctionner.
La norme C++ permet une mise en œuvre à utiliser un type signé pour les énumérations, mais ne l'exige pas. Par conséquent, vous ne pouvez pas en général supposer qu'il est sûr de mettre les nombres négatifs dans un enum.