Quel est l'avantage d'utiliser uint8_t sur unsigned char en C ?
Je sais que sur presque tous les systèmes uint8_t est juste un typedef pour unsigned char , alors pourquoi l'utiliser ?
En utilisant explicitement unsigned char o signed char documente également l'intention, puisque sans fioritures char est ce qui montre que vous travaillez avec des personnages.
@caf : Si vous êtes assez chanceux pour aller au-delà d'un "unsigned" non orné pour commencer, ce que je vois encore des gens faire pour laisser la plateforme choisir si c'est int ou char par défaut. Mais, je pense qu'à notre époque, 'unsigned' (seul, ou orné) indique l'intention de manière adéquate, sinon un simple processus d'élimination l'explique :)
Juste pour être pédant, certains systèmes peuvent ne pas avoir de type 8 bits. D'après Wikipedia :
Une implémentation est tenue de définir des types d'entiers de largeur exacte pour N = 8, 16, 32 ou 64 si et seulement si elle possède un type qui répond aux exigences. Elle n'est pas tenue de les définir pour tout autre N, même si elle prend en charge les types appropriés.
Alors uint8_t n'est pas garanti, mais il existera pour toutes les plateformes où 8 bits = 1 octet. Certaines plateformes embarquées peuvent être différentes, mais cela devient très rare. Certains systèmes peuvent définir char pour être de 16 bits, auquel cas il n'y aura probablement pas de type 8 bits.
En dehors de ce problème (mineur), La réponse de @Mark Ransom est le meilleur à mon avis. Utilisez celui qui montre le plus clairement à quoi vous utilisez les données.
Aussi, je suppose que vous vouliez dire uint8_t (le typedef standard de C99 fourni dans le fichier stdint.h ) plutôt que uint_8 (ne faisant partie d'aucune norme).
@caf, par pure curiosité - pouvez-vous mettre un lien vers la description de certains d'entre eux ? Je sais qu'ils existent parce que quelqu'un en a mentionné un (et a fait un lien vers la documentation du développeur pour celui-ci) dans une discussion comp.lang.c++.moderated sur la question de savoir si les garanties de type C/C++ sont trop faibles, mais je ne trouve plus ce fil de discussion, et c'est toujours pratique d'y faire référence dans des discussions similaires :)
"Certains systèmes peuvent définir les types de chars comme étant de 16 bits, auquel cas il n'y aura probablement pas de type 8 bits d'aucune sorte." - et malgré quelques objections incorrectes de ma part, Pavel a démontré dans sa réponse que si char est de 16 bits, alors même si le compilateur fournit un type 8 bits, cela ne doit pas appelez-le uint8_t (ou le typedef à cela). Cela est dû au fait que le type 8 bits aurait des bits inutilisés dans la représentation de stockage, ce qui a pour effet d'augmenter le nombre de bits non utilisés. uint8_t ne doit pas avoir.
Si vous aviez vraiment des problèmes avec votre code qui ne compile pas sur un système parce que uint8_t n'existe pas, vous pourriez utiliser find et sed pour changer automatiquement toutes les occurrences de uint8_t en unsigned char ou quelque chose de plus utile pour vous.
@bazz - non, si vous supposez qu'il s'agit d'un type 8 bits, vous ne pouvez pas - par exemple pour décompresser des données empaquetées de manière bytewise par un système distant. La supposition implicite est que la raison pour laquelle uint8_t n'existe pas est sur un processeur où un char est plus de 8 bits.
Il y en a peu. Du point de vue de la portabilité, char ne peut pas être inférieur à 8 bits, et rien ne peut être plus petit que char Ainsi, si une implémentation C donnée possède un type d'entier 8 bits non signé, ce sera char . Il se peut aussi qu'il n'en ait pas du tout, auquel cas toute typedef sont discutables.
Il pourrait être utilisé pour mieux documenter votre code dans le sens où il est clair que vous avez besoin d'octets de 8 bits ici et rien d'autre. Mais en pratique, c'est déjà une attente raisonnable pratiquement partout (il existe des plates-formes DSP sur lesquelles ce n'est pas vrai, mais les chances que votre code y soit exécuté sont minces, et vous pourriez tout aussi bien vous tromper en utilisant une assert statique au début de votre programme sur une telle plate-forme).
Pour mémoire, vous pourriez faire un type 8 bits sur n'importe quelle plateforme : typedef struct { unsigned i :8; } uint8_t; mais vous devrez l'utiliser comme uint8_t x; x.i = ... donc ce serait un peu plus encombrant.
Je pense que les caractères peuvent aller jusqu'à 4 bits, en dessous, les choses se dégradent un peu dans la norme (il est possible que je me trompe).
@Skizz - Non, la norme exige que unsigned char doit pouvoir contenir des valeurs comprises entre 0 et 255. Si vous pouvez faire cela en 4 bits, je vous tire mon chapeau.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
