db__ a écrit :
avant de faire du C j'ai fait et continue à faire de l'assembleur. Tous les processeurs que j'ai cotoyés, connaissait l'octet donc pour moi un char est un octet.
|
Alors tu ne connais pas les DSP[1] :
Motorola 56156 : CHAR_BIT = 32
Texas TMS320C54 : CHAR_BIT = 16
et il existe des machines anciennes (PDP11 ou un truc dans le genre) avec CHAR_BIT = 9
Bref, le langage C, qui a vocation universelle, a prévu le cas. Il impose un minimum de 8 bits, mais pas de maximum.
Citation :
Si le standard C était bien foutu (je n'en sait rien) le compilateur devrait faire en sorte que les char soient des octets et gérer les problèmes d'extension de signe lorsque le problème se pose.
|
Ca ferait rajouter du code pas forcément utile et ça nuirait aux performances. Le C considère que le char fait la taille maximale possible, il gère l'extension de signe automatiquement, mais c'est au programmeur de faire les masques nécessaire pour ignorer les bits inutiles si besoin est. (Si on utilise des unsigned, comme il est recommandé avec les opérateurs bitwise, les masquages sont en principe inutiles)
Citation :
si on a un unsigned char qui vaut 0xff et que l'on fait un décalage à gauche de 4 bits, le résultat devrait être 0x00f0 et non 0x0ff0 sur un unsigned char codé sur 16 bits.
|
Oui. unsigned est le mot important.
--------------------------
[1]la mémoire interne des DSP est organisée en mots de 16 ou 32 bits qui interdisent les acces 8-bits. Normal, ils sont orientés calcul et non traitement de chaine. Cependant, ils savent traiter les chaines, mais elles occupent plus de mémoire que nécessaire. C'est tout. C'est pas grave, c'est pas leur vocation.
Message édité par Emmanuel Delahaye le 07-03-2008 à 23:26:12
---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/