Tout le temps je lis des phrases comme
ne comptez pas sur 1 octet de 8 bits
utilisation
CHAR_BIT
au lieu de 8 comme constante pour convertir entre bits et octets
etc. Quels systèmes réels existent-ils aujourd'hui, où cela est vrai? (Je ne sais pas s'il y a des différences entre C et C++ à ce sujet, ou si c'est en fait indépendant du langage. Veuillez réétiqueter si nécessaire.)
Sur les machines plus anciennes, les codes inférieurs à 8 bits étaient assez courants, mais la plupart d'entre eux sont morts et disparus depuis des années.
C et C++ ont imposé un minimum de 8 bits pour char
, au moins aussi loin que la norme C89. [Edit: Par exemple, C90, §5.2.4.2.1 nécessite CHAR_BIT
> = 8 et UCHAR_MAX
> = 255. C89 utilise un numéro de section différent (I croire qui serait §2.2.4.2.1) mais un contenu identique]. Ils traitent "char" et "byte" comme essentiellement synonymes [Edit: par exemple, CHAR_BIT
est décrit comme: "nombre de bits pour le plus petit objet qui n'est pas un champ de bits (octet)".]
Il existe cependant des machines actuelles (principalement des DSP) où le plus petit type est supérieur à 8 bits - un minimum de 12, 14 ou même 16 bits est assez courant. Windows CE fait à peu près la même chose: son plus petit type (au moins avec le compilateur de Microsoft) est de 16 bits. Ils font pas, cependant, traitent un char
comme 16 bits - au lieu de cela ils adoptent l'approche (non conforme) de simplement ne pas supporter un type nommé char
à tout.
AUJOURD'HUI, dans le monde du C++ sur les processeurs x86, il est assez sûr de compter sur un octet de 8 bits. Les processeurs où la taille de Word n'est pas une puissance de 2 (8, 16, 32, 64) sont très peu communs.
Ce n'était pas toujours le cas.
Le processeur central Control Data 6600 (et ses frères) utilisait un mot 60 bits et ne pouvait adresser qu'un mot à la fois. Dans un sens, un "octet" sur un CDC 6600 était de 60 bits.
Le matériel du pointeur d'octets DEC-10 fonctionnait avec des octets de taille arbitraire. Le pointeur d'octets comprenait la taille des octets en bits. Je ne me souviens pas si les octets pouvaient s'étendre sur les limites de Word; Je pense qu'ils ne pouvaient pas, ce qui signifiait que vous auriez quelques bits perdus par mot si la taille des octets n'était pas de 3, 4, 9 ou 18 bits. (Le DEC-10 utilisait un mot 36 bits.)
Sauf si vous écrivez du code qui pourrait être utile sur un DSP, vous avez tout à fait le droit de supposer que les octets sont de 8 bits. Tout le monde n'est peut-être pas un VAX (ou un Intel), mais tout le monde doit communiquer, partager des données, établir des protocoles communs, etc. Nous vivons à l'ère d'Internet bâtie sur des protocoles construits sur des octets, et toute implémentation C où les octets ne sont pas des octets aura beaucoup de mal à utiliser ces protocoles.
Il convient également de noter que POSIX et Windows ont (et mandatent) des octets 8 bits. Cela couvre 100% des machines non embarquées intéressantes, et de nos jours une grande partie des systèmes embarqués non DSP également.
De Wikipedia :
La taille d'un octet a d'abord été choisie pour être un multiple des codes de téléscripteur existants, en particulier les codes à 6 bits utilisés par l'armée américaine (Fieldata) et la marine. En 1963, pour mettre fin à l'utilisation de codes de téléimprimeurs incompatibles par différentes branches du gouvernement américain, ASCII, un code à 7 bits, a été adopté comme norme de traitement des informations fédérales, rendant les octets de 6 bits commercialement obsolètes. Au début des années 1960, AT&T a introduit la téléphonie numérique d'abord sur les lignes interurbaines à longue distance. Celles-ci utilisaient le codage de loi µ à 8 bits. Cet investissement important a promis de réduire les coûts de transmission des données 8 bits. L'utilisation de codes à 8 bits pour la téléphonie numérique a également conduit à l'adoption "d'octets" de données à 8 bits comme unité de données de base du premier Internet.
En tant que programmeur moyen sur les plates-formes grand public, vous avez pas besoin de trop vous soucier d'un octet qui ne soit pas 8 bits. Cependant, j'utiliserais toujours le CHAR_BIT
constante dans mon code et assert
(ou mieux static_assert
) tous les emplacements où vous comptez sur des octets de 8 bits. Cela devrait vous mettre du bon côté.
(Je ne connais aucune plateforme pertinente où cela ne se vérifie pas).
Premièrement, le nombre de bits dans char
ne dépend pas formellement du "système" ou de la "machine", même si cette dépendance est généralement impliquée par le bon sens. Le nombre de bits dans char
dépend uniquement de implémentation (c'est-à-dire du compilateur). Il n'y a aucun problème à implémenter un compilateur qui aura plus de 8 bits dans char
pour tout système ou machine "ordinaire".
Deuxièmement, il existe plusieurs plates-formes embarquées où sizeof(char) == sizeof(short) == sizeof(int)
, chacune ayant 16 bits (je ne me souviens pas des noms exacts de ces plates-formes). De plus, les machines Cray bien connues avaient des propriétés similaires, tous ces types ayant 32 bits.
Dans l'histoire, il existait un tas d'architectures étranges qui n'utilisaient pas de tailles de mots natives où des multiples de 8. Si vous rencontrez l'un de ces éléments aujourd'hui, faites-le moi savoir.
La taille de l'octet a été historiquement dépendante du matériel et il n'existe aucune norme définitive qui impose la taille.
Ce pourrait être une bonne chose à garder à l'esprit si vous faites beaucoup de choses intégrées.
Ajouter un de plus comme référence, à partir de l'entrée Wikipedia sur HP Saturn :
L'architecture de Saturne est basée sur un quartet; c'est-à-dire que l'unité centrale de données est de 4 bits, qui peuvent contenir un chiffre décimal codé binaire (BCD).
Je fais beaucoup de code embarqué et travaille actuellement sur le code DSP avec CHAR_BIT de 16