Faut-il toujours utiliser 'int' pour les nombres en C, même si elles sont non-négatives?

Dois-je toujours ...

La réponse à "dois-je toujours ..." est presque certainement "non", il y a beaucoup de facteurs qui déterminent si vous devez utiliser un type de données - la cohérence est importante.

Mais, c'est un très subjective de la question, il est vraiment facile de gâcher unsigneds:

for (unsigned int i = 10; i >= 0; i--);

résultats dans une boucle infinie.

C'est pourquoi certains guides de style, y compris Google C++ Guide de Style décourager unsigned types de données.

Dans mon opinion personnelle, je n'ai pas rencontré de nombreux bugs causés par ces problèmes avec des unsigned types de données, je dirais, utilisez les assertions de vérifier votre code et de les utiliser judicieusement (et moins lorsque vous effectuez l'arithmétique).

Dans certains cas, vous devez utiliser unsigned integer types sont:

• Vous avez besoin pour traiter une donnée comme une pure représentation binaire.
• Vous avez besoin de la sémantique de l'arithmétique modulo vous obtenez avec des nombres non signés.
• Vous avez à l'interface avec le code qui utilise les types non signés (par exemple, la norme de la bibliothèque de routines qui acceptent de rendement/size_t valeurs.

Mais pour le général, l'arithmétique, la chose est, quand vous dites que quelque chose "ne peut pas être négatif," cela ne veut pas nécessairement dire que vous devez utiliser un type non signé. Parce que vous peut mettre une valeur négative dans un unsigned, c'est juste qu'il va devenir une très grande valeur quand vous allez sortir. Donc, si vous voulez dire que les valeurs négatives sont interdites, comme pour une base de la racine carrée de la fonction, alors vous êtes en indiquant une condition préalable de la fonction, et vous devriez le faire valoir. Et vous ne pouvez pas affirmer que ce qui ne peut l'être, est; vous avez besoin d'un moyen de tenir out-of-band valeurs de sorte que vous pouvez les tester (c'est le même genre de logique derrière getchar() retour d'un int et pas char.)

En outre, le choix de l'signé-vs-non signé peut avoir des répercussions sur la performance, ainsi. Jetez un oeil à l' (fictive) de code ci-dessous:

#include <stdbool.h>

bool foo_i(int a) {
    return (a + 69) > a;
}

bool foo_u(unsigned int a)
{
    return (a + 69u) > a;
}

Les deux foo's sont les mêmes, sauf pour le type de leurs paramètres. Mais, lorsqu'il est compilé avec c99 -fomit-frame-pointer -O2 -S, vous obtenez:

 .fichier "essai.c" 
.texte 
.p2align 4,,15 
.globl foo_i 
.type foo_i, @fonction 
foo_i: 
movl $1, %eax 
ret 
.taille foo_i, .-foo_i 
.p2align 4,,15 
.globl foo_u 
.type foo_u, @fonction 
foo_u: 
movl 4(%esp), %eax 
leal 69(%eax), %edx 
cmpl %eax, %edx 
seta %al 
ret 
.taille foo_u, .-foo_u 
.ident "GCC: (Debian 4.4.4-7) 4.4.4" 
.de la section .remarque.GNU-de la pile",",@progbits 

Vous pouvez voir que foo_i() est plus efficace que foo_u(). C'est parce que unsigned de dépassement de capacité arithmétique est défini par la norme pour "envelopper", de sorte (a + 69u) peut très bien être plus petit que a si a est très grand, et donc il doit y avoir des code pour ce cas. D'autre part, signé de dépassement de capacité arithmétique est pas défini, donc GCC va aller de l'avant et d'assumer arithmétique signée n'est pas de débordement, et ainsi de (a + 69) ne peut pas jamais être inférieure à a. Le choix de types non signés sans discernement peut donc limiter l'impact direct sur les performances.

La réponse est Oui. Le "unsigned int type de C et de C++ n'est pas un "toujours entier positif", quel que soit le nom du type ressemble. Le comportement de C/C++ unsigned ints n'a pas de sens si vous essayez de lire le type "non négatif"... par exemple:

• La différence de deux unsigned est un nombre non signé (n'a pas de sens si vous l'avez lu comme "La différence entre les deux nombres négatifs est non-négatif")
• L'ajout d'un int et unsigned int unsigned
• Il y a une conversion implicite de int unsigned int (si vous lisez unsigned comme "non négatif" c'est la en face de de conversion qui serait logique)
• Si vous déclarez une fonction acceptant un unsigned paramètre lorsque quelqu'un passe un négatif int vous obtenez tout simplement qu'implicitement converti en une énorme valeur positive; en d'autres termes à l'aide d'un unsigned type de paramètre n'est pas de vous aider à trouver les erreurs ni au moment de la compilation, ni au moment de l'exécution.

En effet, non signé nombre est très utile pour certains cas parce qu'ils sont des éléments de l'anneau des entiers-modulo-N", N étant une puissance de deux. Unsigned ints sont utiles lorsque vous souhaitez l'utiliser modulo-n arithmétique, ou comme des masques de bits; ils ne sont PAS utiles, car les quantités.

Malheureusement en C et C++ non signés ont également été utilisés pour représenter les non-négatif quantités pour être en mesure d'utiliser tous les 16 bits lorsque les entiers où ce petit... à ce moment, être en mesure d'utiliser 32k ou 64 ko a été considéré comme une grande différence. J'avais le classer comme un accident historique... vous ne devriez pas essayer de lire une logique, car il n'y a pas de logique.

Par la façon dont, à mon avis, c'était une erreur... si 32k ne sont pas assez puis très bientôt de 64 ko de ne pas être suffisant; abusant de la modulo entier juste parce que d'un bit supplémentaire à mon avis, est d'un coût trop élevé à payer. Bien sûr, il aurait été raisonnable de le faire si une bonne non-type négatif était présent ou défini... mais non signé sémantique est tout à fait inacceptable pour l'utiliser en tant que non-négatif.

Parfois, vous pouvez trouver qui a dit que non signé est bon parce qu'il "documents" que vous ne voulez valeurs non négatives... cependant que la documentation est de valeur que pour ceux qui ne le savent pas vraiment comment unsigned travaille pour le C ou le C++. Pour moi, voir un type non signé utilisée pour les valeurs non négatives signifie simplement que qui a écrit le code ne comprends pas la langue, sur cette partie.

Si vous comprenez vraiment et souhaitez le "wrapping" comportement des entiers non signés alors qu'ils sont le bon choix (par exemple, j'ai presque toujours utiliser "unsigned char" quand je suis à la manipulation d'octets); si vous n'allez pas utiliser l'emballage comportement (et que le comportement est juste va être un problème pour vous, comme dans le cas de la différence vous le montre), alors c'est un indicateur clair que le type non signé est un mauvais choix et vous devez vous en tenir à la plaine ints.

Cela veut dire que le C++ std::vector<>::size() type de retour est un mauvais choix ? Oui... c'est une erreur. Mais si vous le dites alors soyez prêt à être appelé mauvais noms par ceux qui ne comprennent pas que le "non signé" le nom est juste un nom... ce qu'il compte c'est le comportement et qui est une "modulo n" comportement (et ne serait d'envisager un "modulo n" type de la taille d'un conteneur à un choix judicieux).

if (bitsAvailable >= optionalDataSize + mandatoryDataSize) {
    //Optional data fits, so add it to the header.
}

Sans Bug, tant que mandatoryDataSize + optionalDataSize ne peut pas déborder le type entier non signé -- la dénomination de ces variables, m'amène à croire que c'est probablement le cas.

À partir des commentaires sur l'un de Eric Lipperts billets de Blog (Voir ici):

Jeffrey L. Whitledge

Une fois, j'ai développé un système dans lequel
les valeurs négatives n'a pas de sens en tant que
paramètre, alors plutôt que de valider
que les valeurs des paramètres ont été
non négatif, je pensais que ce serait un
la grande idée de l'utiliser juste uint à la place. J'
rapidement découvert que chaque fois que je
utilisé ces valeurs pour rien (comme
l'appel de la BCL méthodes), qu'ils avaient
convertis en entiers signés. Cette
j'ai dû, pour valider que l'
les valeurs de ne pas dépasser la signé
entier de gamme sur l'extrémité supérieure, de sorte que je
rien gagné. Aussi, chaque fois que l'
le code a été appelé, les services de renseignements qui ont été
utilisé (souvent reçu de BCL
fonctions) ont dû être converties à
les nombres uint compris. Il n'a pas fallu longtemps avant que je
changé toutes ces nombres uint compris retour à l'ints
et pris tout ce qui inutiles casting
out. J'ai encore à valider le fait que la
les numéros ne sont pas négatives, mais le code
est beaucoup plus propre!

Eric Lippert

Ne pouvais pas dit mieux moi-même.
Vous presque jamais besoin de la portée d'un
uint, et ils ne sont pas conformes CLS.
La manière standard de représenter une petite
entier est avec "int", même si il y
sont des valeurs qui sont hors de
gamme. Une bonne règle de base: seules les utiliser
"uint" pour les situations où vous êtes
interopérabilité avec du code non managé
qui attend les nombres uint compris, ou lorsque le
entier en question est clairement utilisé comme
un ensemble de bits, pas un numéro. Toujours
essayez de l'éviter dans les interfaces publiques.
- Eric

Non, vous devez utiliser le type qui est bon pour votre demande. Il n'y a pas de règle d'or. Parfois sur de petits microcontrôleurs il est par exemple plus rapide et efficace en terme de mémoire à utiliser-dire 8 ou 16 bits variables dans la mesure du possible, comme c'est souvent le natif du chemin de données de taille, mais c'est un cas très spécial. Je recommande également à l'aide de stdint.h dans la mesure du possible. Si vous utilisez visual studio, vous pouvez trouver des versions sous licence BSD.

Vous aurez besoin de regarder les résultats des opérations que vous effectuez sur les variables pour vérifier si vous pouvez obtenir plus de/underflows - dans votre cas, le résultat étant potentiellement négatifs. Dans ce cas, vous êtes mieux d'utiliser l'signé équivalents.

Si vos numéros de devrait jamais être inférieur à zéro, mais ont une chance d'être < 0, par tous les moyens d'utiliser les entiers signés et saupoudrer des assertions ou des autres d'exécution des contrôles autour de. Si vous êtes vraiment en train de travailler avec 32 bits (ou 64, ou 16, selon votre architecture cible) valeurs où le bit le plus significatif signifie autre chose que "-", vous ne devriez utiliser unsigned variables pour les tenir. Il est plus facile de détecter les débordements d'entiers où un nombre qui doit toujours être positive est très négatif que quand c'est nul, donc si vous n'avez pas besoin que peu, aller avec le signé une.