la declaration des bits field

bonjours,

Code:

---

1 2 3 4 5

struct bit_field{ unsigned char element1 :4; unsigned char element2 :4; };

---

est ce je suis entrain d'utiliser le meme octet en memoire ou je suis entrain de declarer de octet memoire??
c.a.d est ce que je suis entrain de gagner de l'espace memoire???


merci d'avance!!!

Chaque char va occupé un octet. Donc ici tu occuperas deux octets...


ps : c'est pas le bon endroit pour poster, y'a pas d'utilisation de la SL dans ton code.

donc si je comprend bien je ne gagne rien de point de vue ocuppation de la memoire et donc les bits fields n'ajoute rien???

Citation:

---

Chaque char va occupé un octet. Donc ici tu occuperas deux octets...

---

Pas du tout.
Les champs de bits sont compactés. Par contre l'ordre (du lsb vers le msb ou l'inverse) des champs de bits dépend de l'implémentation

et bah voilà la solution !
j'ai affiché le sizeof() de la structure j'ai trouvé que c'est 1 octet et donc la taille de la structure est un octet!
les bits fields c'est bien! :king:

Citation:

---

Envoyé par jeanjack

les bits fields c'est bien! :king:

---

Oui, mais attention, ce n'est pas portable :cry:

tu veux dire quoi avec ce n'est pas portable??
n'est ce pas du standard????

Citation:

---

Envoyé par jeanjack

n'est ce pas du standard????

---

Si c'est standard et tous les compilateurs C savent le faire par contre, l'implémentation qu'il y a derrière (sous le capot) n'est pas portable.

Certains compilateurs peuvent utiliser un octet pour y ranger 1 bit et d'autres utiliser un octet pour y ranger 8 bits (je sais je pousse un peu le trait mais c'est l'idée)
Certains pourrait dire le bit de poid faible, c'est le bit 0 et d'autres dire que c'est le bit 7 qui est le bit de poids faible.

Donc tout les compilateurs savent donc gérer des champs de bits mais ils ne le font pas tous de la même manière (parce que la norme ne l'impose pas)

ah!! j'ai compris de quoi tu parle!!
tu veux dire que je dois tenir compte du

Code:

---

BYTE_ORDER

---

et faire appel à la bbliothèque endian si c'est cela le problème, j'ai tenu compte dès le début sinon explique moi encore. merci:king:

Le byte order est peut être une partie du problème mais le problème principal est que la norme ne dit pas comment implémenter la notion de bit field. A partir de ce moment là, les compilateurs font ce qu'il veulent et donc ce n'est pas portable.

La norme ne précise pas nom plus comment doit être implémenter les autres types (int, float, ...).

Bref, les bits fields, comme les autres types, ce n'est pas portable de les utiliser de façon non portable ;)

Et comme, sur des machines avec assez de mémoire, l'utilisation non-portable est la seule utilisation des bitfields qui vienne à l'esprit, le manque de normalisation dépouille les bitfields de toute utilité.

Donc, dès que tu veux un minimum de portabilité, les bitfields ne servent à rien.

À moins que: Il est possible que l'agencement des bitfields soit normalisé sous POSIX. Je n'en ai aucune idée, mais ça les rendrait utiles sur tout système compatible POSIX...