octet -> 2quartet - C - Programmation
Marsh Posté le 21-09-2005 à 12:35:26
Bonjour
Il est curieux d'utiliser un int pour stocker un octet
quartet1 = octet & 0xf;
quartet2 = (octet & 0xf0) >> 4;
le & 0xf0 devient inutile si octet est défini comme un char
Marsh Posté le 21-09-2005 à 13:37:18
db__ a écrit : Il est curieux d'utiliser un int pour stocker un octet |
Pourquoi ?
Citation : |
Non, car rien ne garanti qu'un char fasse exactement 8 bits. Il peut faire plus (voir CHAR_BIT de <limits.h> ).
De plus , il n'est pas inutile de préciser que quartet1 reçoit le quartet LSB et quartet2 le quartet MSB.
Marsh Posté le 21-09-2005 à 13:44:10
merci j'avais pas penser a faire ca comme ca.
cette solution me plait :-)
Marsh Posté le 21-09-2005 à 14:27:02
ReplyMarsh Posté le 21-09-2005 à 14:29:18
schmur a écrit : petite modification |
Certainement pas. La solution de DB__ était bonne.
|
Marsh Posté le 21-09-2005 à 14:34:25
Emmanuel Delahaye a écrit : Certainement pas. La solution de DB__ était bonne. |
mille excuse
t'as bien raison, j'a fait une erreur de frappe lors de mes testes.
desole de ma betisse ! honte à moi
Marsh Posté le 22-09-2005 à 12:41:57
Bonjour
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. 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.
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.
Si ce n'est pas le cas, a quoi sert le type char sur un processeur ne gérant pas les octets ?
gérer économiquement sa mémoire en utilisant des char codé sur un octet au lieu de 32 (voir 64) bits pour stocker le dit octet me semble plus rationnel tant qu'on utilise pas l'unicode32.
Marsh Posté le 22-09-2005 à 13:07:40
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 :
|
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 :
|
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.
Marsh Posté le 21-09-2005 à 12:26:49
bonjour,
je me demandai s'il existe une maniére simple de mettre en octet en deux quartet :
int octet =...
int quartet1=0
int quartet2=0
function magique(octet, *quartet1, *quartet2)
merci d'avance
edit : quartet1 poids fort et quartet2 poids faible ou inversement bien sur
Message édité par schmur le 21-09-2005 à 12:34:10