uint8_t vs caractère non signé

Quel est l'avantage d'utiliser uint8_tover unsigned charen C?

Je sais que sur presque tous les systèmes, ce uint8_tn'est qu'un typedef unsigned char, alors pourquoi l'utiliser?

Il documente votre intention - vous stockerez de petits nombres, plutôt qu'un caractère.

De plus, cela semble plus agréable si vous utilisez d'autres types de caractères tels que uint16_tou int32_t.

Juste pour être pédant, certains systèmes peuvent ne pas avoir un type 8 bits. Selon Wikipedia :

Une implémentation est requise pour définir des types entiers de largeur exacte pour N = 8, 16, 32 ou 64 si et seulement si elle a un type qui répond aux exigences. Il n'est pas nécessaire de les définir pour tout autre N, même s'il prend en charge les types appropriés.

Il uint8_tn'est donc pas garanti d'exister, bien qu'il le soit pour toutes les plates-formes où 8 bits = 1 octet. Certaines plates-formes intégrées peuvent être différentes, mais cela devient très rare. Certains systèmes peuvent définir des chartypes sur 16 bits, auquel cas il n'y aura probablement aucun type sur 8 bits.

À part ce problème (mineur), la réponse de @Mark Ransom est la meilleure à mon avis. Utilisez celui qui montre le plus clairement pourquoi vous utilisez les données.

En outre, je suppose que vous vouliez dire uint8_t(le typedef standard de C99 fourni dans l'en- stdint.htête) plutôt que uint_8(ne faisant partie d'aucune norme).

Le but est d'écrire du code indépendant de l'implémentation. unsigned charn'est pas garanti comme étant de type 8 bits. uint8_test (si disponible).

Comme vous l'avez dit, " presque tous les systèmes".

charest probablement l'un des moins susceptibles de changer, mais une fois que vous commencez à utiliser uint16_tet vos amis, vous utilisez uint8_tmieux les mélanges, et peut même faire partie d'une norme de codage.

D'après mon expérience, il y a deux endroits où nous voulons utiliser uint8_t pour signifier 8 bits (et uint16_t, etc.) et où nous pouvons avoir des champs inférieurs à 8 bits. Les deux endroits sont où l'espace compte et nous avons souvent besoin de regarder un vidage brut des données lors du débogage et de pouvoir déterminer rapidement ce qu'il représente.

Le premier concerne les protocoles RF, en particulier dans les systèmes à bande étroite. Dans cet environnement, nous devrons peut-être regrouper autant d'informations que possible dans un seul message. Le second est dans le stockage flash où nous pouvons avoir un espace très limité (comme dans les systèmes embarqués). Dans les deux cas, nous pouvons utiliser une structure de données compressée dans laquelle le compilateur se chargera de l'emballage et du déballage pour nous:

#pragma pack(1)
typedef struct {
  uint8_t    flag1:1;
  uint8_t    flag2:1;
  padding1   reserved:6;  /* not necessary but makes this struct more readable */
  uint32_t   sequence_no;
  uint8_t    data[8];
  uint32_t   crc32;
} s_mypacket __attribute__((packed));
#pragma pack()

La méthode que vous utilisez dépend de votre compilateur. Vous devrez peut-être également prendre en charge plusieurs compilateurs différents avec les mêmes fichiers d'en-tête. Cela se produit dans les systèmes embarqués où les périphériques et les serveurs peuvent être complètement différents - par exemple, vous pouvez avoir un périphérique ARM qui communique avec un serveur Linux x86.

Il y a quelques mises en garde concernant l'utilisation de structures compactes. Le plus gros problème est que vous devez éviter de déréférencer l'adresse d'un membre. Sur les systèmes avec des mots alignés sur plusieurs octets, cela peut entraîner une exception mal alignée - et un coredump.

Certaines personnes s'inquiéteront également des performances et soutiendront que l'utilisation de ces structures compressées ralentira votre système. Il est vrai que, dans les coulisses, le compilateur ajoute du code pour accéder aux membres de données non alignés. Vous pouvez le voir en regardant le code assembleur dans votre IDE.

Mais comme les structures compressées sont les plus utiles pour la communication et le stockage des données, les données peuvent être extraites dans une représentation non compressée lorsque vous travaillez avec elles en mémoire. Normalement, nous n'avons pas besoin de travailler avec le paquet de données entier en mémoire de toute façon.

Voici quelques discussions pertinentes:

pragma pack (1) ni __attribute__ ((aligné (1))) fonctionne

Le pack __attribute __ ((emballé)) / #pragma de gcc est-il dangereux?

http://solidsmoke.blogspot.ca/2010/07/woes-of-structure-packing-pragma-pack.html

Il y a peu. Du point de vue de la portabilité, charne peut pas être inférieur à 8 bits, et rien ne peut être inférieur à char, donc si une implémentation C donnée a un type entier 8 bits non signé, ce sera le cas char. Alternativement, il peut ne pas en avoir du tout, à quel point les typedefastuces sont sans objet.

Il pourrait être utilisé pour mieux documenter votre code dans un sens qu'il est clair que vous avez besoin d'octets 8 bits et rien d'autre. Mais dans la pratique, c'est une attente raisonnable pratiquement n'importe où déjà (il existe des plates-formes DSP sur lesquelles ce n'est pas vrai, mais les chances que votre code s'exécute là-bas sont minces, et vous pourriez tout aussi bien vous tromper en utilisant une assertion statique en haut de votre programme sur une telle plateforme).

C'est très important par exemple lorsque vous écrivez un analyseur de réseau. les en-têtes de paquet sont définis par la spécification du protocole, et non par le fonctionnement du compilateur C d'une plate-forme particulière.

Sur presque tous les systèmes, j'ai rencontré uint8_t == char non signé, mais ce n'est pas garanti par la norme C. Si vous essayez d'écrire du code portable et que la taille de la mémoire est exacte, utilisez uint8_t. Sinon, utilisez un caractère non signé.