Action de l'opérateur ":"

Bonjour,
voila je suis tombé sur le code suivant:

Code:

---

1 2	unsigned char po:4;

---

Que signifie ":4" ?

J'ai pourtant cherché dans la msdn, sur le net et j'ai pas trouvé grand chose... (une inversion ??)

J'ai même testé par le biais de ce petit programme:

Code:

---

1 2 3 4 5 6 7 8

unsigned char a; unsigned char b:4;   a = 0x69; b = 0x69;   eet les printf associé

---

J'obtiens comme résultat:
a= 69
b = 06


Si quelqu'un peut m'éclairer sur le sujet ??? Merci d'avance

C'est un champ de bits (bit field). Particulierement utile dans les structures pour compresser des flags dans un unsigned. Sinon, a utiliser avec precaution.

??? merci mais je n'ai pas mieux compris :roll:

En fait si j'ai bien compris, quand tu fais <type> <nom_variable>:<chiffre> ta variable se retrouve sur <chiffre> bits au lieu de la taille classique de ton <type>.

Citation:

---

Envoyé par MonsieurAk

??? merci mais je n'ai pas mieux compris :roll:

---

Tu peux par exemple les utiliser pour decomposer des variables par exemple si tu veux mettre dans des champs chaque bit d'un char tu utilise un champs de bits

Code:

---

1 2 3 4 5 6

typedef struct DecompoChar{ unsigned a:1 unsigned b:1 ... // 8 fois };

---

Mais c'est a utiliser avec beaucoup de precautions (notamment big et little endian)

ok !
Merci !

Un bit field est une maniere de creer un "type" sur moins de bits que le minimum adressable par la machine (8, en general). Evidemment, tu ne travailleras pas avec une variable de 4 bits, dans ton exemple, mais tu n'utilises que les 4 premiers bits de ton unsigned int.

Les bit fields sont utiles dans les structures pour compresser des donnees qui ne prennent pas toute la plage de valeur disponible. Les bit fields ne sont pas portables (notamment si la longueur totale depasse celle du mot de la machine - dans ce cas, les compilateurs font des choix differents).

L'interet des bit fields etait d'economiser la memoire au maximum, mais ils sont a eviter en general.

Citation:

---

Envoyé par MonsieurAk

Bonjour,
voila je suis tombé sur le code suivant:

Code:

---

1 2	unsigned char po:4;

---

---

N'existe pas comme ça tout seul en standard. C'est peut être une extension supportée par ton compilateur.

Par contre ce qui existe, ce sont les 'champs de bits', qui sont définis ainsi :

Code:

---

1 2 3 4 5

struct <tag> { <type> <champ> : <largeur>; };

---

avec

• tag : nom de la structure
• type : int ou unsigned int ou [C99] _Bool ou bool
• champ : identificateur
• largeur : nombre de bits de la variable (1 à 16 (minimum garanti par le langage)).

Nota : l'ordre des champs dans un champ de bits n'est pas défini par le langage, mais par l'implémentation.

Citation:

---

Envoyé par Skyrunner

Tu peux par exemple les utiliser pour decomposer des variables par exemple si tu veux mettre dans des champs chaque bit d'un char tu utilise un champs de bits

Code:

---

1 2 3 4 5 6

typedef struct DecompoChar{ unsigned a:1 unsigned b:1 ... // 8 fois };

---

---

C'est justement ce genre d'application qui n'est pas portable (utiliser les opérateurs binaires, qui eux sont portables).

Par contre, c'est utile pour réduire la taille d'une structure de données. Inutile d'utiliser 16 bits pour stocker des valeurs 0 ou 1 (x:1) ou 1 à 3 (y:2) etc. Très intéressant si on a des centaines d'objets de ce type...

oh j'y vois donc une grande utilité notamment optimisation de l'utilité de la mémoire..

Citation:

---

C'est justement ce genre d'application qui n'est pas portable

---

Mais ce n'est pas portable ? (Uniquement OS Windows ??)

Citation:

---

Envoyé par MonsieurAk

Mais ce n'est pas portable ? (Uniquement OS Windows ??)

---

Non, c'est du C standard, mais la facon dont c'est implemente varie d'une machine et d'un compilateur a l'autre. On ne peut donc pas se reposer sur un comportement (utilisation des bits de debut ou de fin, depassement de la taille d'un unsigned int) car il va varier.

Alors le mieux c'est de ne pas utiliser de tels mécanismes si on désire un code au maximum portable (dans mon cas pour des systèmes Unix ou Windows)
Non ?

Citation:

---

Envoyé par MonsieurAk

Alors le mieux c'est de ne pas utiliser de tels mécanismes si on désire un code au maximum portable

---

C'est exact. Les solutions non portables sont parfois indispensables, mais leur usage doit etre justifie et clairement indique dans le code par les commentaires adequats (et la version du code pour les autres systemes doit etre mise a disposition, si possible).

Citation:

---

Envoyé par MonsieurAk

Alors le mieux c'est de ne pas utiliser de tels mécanismes si on désire un code au maximum portable (dans mon cas pour des systèmes Unix ou Windows)
Non ?

---

Ca dépend de ce qu'on veut faire. Si on veut réduire la taille d'une structure c'est portable en ce sens qu'ine structure est interne. Si c'est pour mapper des bits sur un registre hard ou un octet de réseau ou de fichier, ce n'est pas portable.

voici le lien ou j'ai trouvé:
http://www.frameip.com/librairie/

Donc à priori ce n'est pas portable (IP header)

Citation:

---

Envoyé par MonsieurAk

voici le lien ou j'ai trouvé:
http://www.frameip.com/librairie/

Donc à priori ce n'est pas portable (IP header)

---

Exact. C'est une implémentation particulière qui peut fonctionner sur une certaine cible. Le tout est de savoir ce qu'on fait. S'ajoutent aux problèmes des champs de bits, les problèmes liés aux structures et aux éventuels bytes d'alignement...

La seule façon portable de traiter les flux de bytes est la combinaison tableau de unsigned char / opérateurs bits (bitwise operators).

Les structures et les champs de bits ne sont pas une solution portable pour implémenter des interfaces externes.

ok merci...