Il s'agit d'entiers spécifiant la largeur des champs de bits nommés res1 (4 bits), doff (4 bits) et fin (1 bit) associés.
Un champ de bit est vu comme un entier signé ou non codé sur le nombre de bits spécifiés (apparement non signé ici). Le type du champ de bit est (doit être ?) un int ou unsigned int (ou encore un autre type entier dépendant de l'implémentation), qualifié (const, register, ...) ou non.
struct titi { /* a est vu comme un entier signé sur 3 bits (de -4 à 3) */ int a :3; /* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */ unsigned int b :3; };
res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre spécifiant la largeur du champ de bit doit être un entier positif qui ne doit pas excéder le nombre de bits d'un objet du type spécifié : exple :
struct toto { int a :32; /*dangereux, int peut être codé sur 16 bits sur certaines plate-formes */ };
Merci...
Salut,
"Zouplaz" <pouet@pouet.com> a écrit dans le message de news:
Xns948DBE17BD2E2Zoupla@212.27.42.70...
Il s'agit d'entiers spécifiant la largeur des champs de bits nommés res1 (4
bits), doff (4 bits) et fin (1 bit) associés.
Un champ de bit est vu comme un entier signé ou non codé sur le nombre de
bits spécifiés (apparement non signé ici).
Le type du champ de bit est (doit être ?) un int ou unsigned int (ou encore
un autre type entier dépendant de l'implémentation), qualifié (const,
register, ...) ou non.
struct titi {
/* a est vu comme un entier signé sur 3 bits (de -4 à 3) */
int a :3;
/* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */
unsigned int b :3;
};
res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre
spécifiant la largeur du champ de bit doit être
un entier positif qui ne doit pas excéder le nombre de bits d'un objet du
type spécifié :
exple :
struct toto {
int a :32; /*dangereux, int peut être codé sur 16 bits sur certaines
plate-formes */
};
Il s'agit d'entiers spécifiant la largeur des champs de bits nommés res1 (4 bits), doff (4 bits) et fin (1 bit) associés.
Un champ de bit est vu comme un entier signé ou non codé sur le nombre de bits spécifiés (apparement non signé ici). Le type du champ de bit est (doit être ?) un int ou unsigned int (ou encore un autre type entier dépendant de l'implémentation), qualifié (const, register, ...) ou non.
struct titi { /* a est vu comme un entier signé sur 3 bits (de -4 à 3) */ int a :3; /* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */ unsigned int b :3; };
res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre spécifiant la largeur du champ de bit doit être un entier positif qui ne doit pas excéder le nombre de bits d'un objet du type spécifié : exple :
struct toto { int a :32; /*dangereux, int peut être codé sur 16 bits sur certaines plate-formes */ };
Merci...
Zouplaz
Régis Troadec - :
Il s'agit d'entiers spécifiant la largeur des champs de bits nommés res1 (4 bits), doff (4 bits) et fin (1 bit) associés.
Un champ de bit est vu comme un entier signé ou non codé sur le nombre de bits spécifiés (apparement non signé ici). Le type du champ de bit est (doit être ?) un int ou unsigned int (ou encore un autre type entier dépendant de l'implémentation), qualifié (const, register, ...) ou non.
struct titi { /* a est vu comme un entier signé sur 3 bits (de -4 à 3) */ int a :3; /* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */ unsigned int b :3; };
res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre spécifiant la largeur du champ de bit doit être un entier positif qui ne doit pas excéder le nombre de bits d'un objet du type spécifié : exple :
struct toto { int a :32; /*dangereux, int peut être codé sur 16 bits sur certaines plate-formes */ };
Bon, je suis pas certain de bien piger...
struct cafait8bits { unsigned int a :2; unsigned int b :2; unsigned int c :1; unsigned int d :3; };
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ? Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Heu...
Régis Troadec - regt@wanadoo.fr :
Il s'agit d'entiers spécifiant la largeur des champs de bits nommés
res1 (4 bits), doff (4 bits) et fin (1 bit) associés.
Un champ de bit est vu comme un entier signé ou non codé sur le nombre
de bits spécifiés (apparement non signé ici).
Le type du champ de bit est (doit être ?) un int ou unsigned int (ou
encore un autre type entier dépendant de l'implémentation), qualifié
(const, register, ...) ou non.
struct titi {
/* a est vu comme un entier signé sur 3 bits (de -4 à 3) */
int a :3;
/* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */
unsigned int b :3;
};
res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre
spécifiant la largeur du champ de bit doit être
un entier positif qui ne doit pas excéder le nombre de bits d'un objet
du type spécifié :
exple :
struct toto {
int a :32; /*dangereux, int peut être codé sur 16 bits sur
certaines
plate-formes */
};
Bon, je suis pas certain de bien piger...
struct cafait8bits {
unsigned int a :2;
unsigned int b :2;
unsigned int c :1;
unsigned int d :3;
};
Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ? Et que sans ça il
aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour
décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Il s'agit d'entiers spécifiant la largeur des champs de bits nommés res1 (4 bits), doff (4 bits) et fin (1 bit) associés.
Un champ de bit est vu comme un entier signé ou non codé sur le nombre de bits spécifiés (apparement non signé ici). Le type du champ de bit est (doit être ?) un int ou unsigned int (ou encore un autre type entier dépendant de l'implémentation), qualifié (const, register, ...) ou non.
struct titi { /* a est vu comme un entier signé sur 3 bits (de -4 à 3) */ int a :3; /* b est vu comme un entier non signé sur 3 bits (de 0 à 7) */ unsigned int b :3; };
res1 occupe 4 bits en mémoire, doff pareil et fin 1 bit. Le nombre spécifiant la largeur du champ de bit doit être un entier positif qui ne doit pas excéder le nombre de bits d'un objet du type spécifié : exple :
struct toto { int a :32; /*dangereux, int peut être codé sur 16 bits sur certaines plate-formes */ };
Bon, je suis pas certain de bien piger...
struct cafait8bits { unsigned int a :2; unsigned int b :2; unsigned int c :1; unsigned int d :3; };
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ? Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Heu...
Anthony FLEURY
Zouplaz wrote:
Bon, je suis pas certain de bien piger...
struct cafait8bits { unsigned int a :2;
2 bits donc 4 valeurs possibles : 0, 1, 2, 3
unsigned int b :2;
Pareil
unsigned int c :1;
Ici c'est un booleen en clair, 0 ou 1.
unsigned int d :3;
Et ici ca va donc de 0 à 7.
};
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ? Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Heu...
Salut, C'est bien ca. Par contre, tu n'es pas assuré que sizeof(struct cafait8bits); soit d'exactement 1 byte car rien n'empêche les bits de paddings. Tu es seulement assuré qu'il n'y en aura pas au début de la structure, et donc que l'adresse de a et l'adresse de ta structure sont les mêmes, comme dans toute structure en fait. C'est donc une commodité du langage pour representer les champs de bits.
De plus, savoir où sont les bits de poids fort ca dépend de ta convention et de ta machine (little endian, big endian...).
Anthony -- "I should have seen it would be this way I should have known from the start what she's up to When you have loved and you've lost someone You know what it feels like to lose" -- The Rasmus
Zouplaz wrote:
Bon, je suis pas certain de bien piger...
struct cafait8bits {
unsigned int a :2;
2 bits donc 4 valeurs possibles : 0, 1, 2, 3
unsigned int b :2;
Pareil
unsigned int c :1;
Ici c'est un booleen en clair, 0 ou 1.
unsigned int d :3;
Et ici ca va donc de 0 à 7.
};
Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ? Et que sans ça il
aurait fallu stocker le tout dans un unsigned char et effectuer des >>
pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Heu...
Salut,
C'est bien ca.
Par contre, tu n'es pas assuré que sizeof(struct cafait8bits); soit
d'exactement 1 byte car rien n'empêche les bits de paddings. Tu es
seulement assuré qu'il n'y en aura pas au début de la structure, et donc
que l'adresse de a et l'adresse de ta structure sont les mêmes, comme dans
toute structure en fait.
C'est donc une commodité du langage pour representer les champs de bits.
De plus, savoir où sont les bits de poids fort ca dépend de ta convention et
de ta machine (little endian, big endian...).
Anthony
--
"I should have seen it would be this way
I should have known from the start what she's up to
When you have loved and you've lost someone
You know what it feels like to lose" -- The Rasmus
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ? Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Heu...
Salut, C'est bien ca. Par contre, tu n'es pas assuré que sizeof(struct cafait8bits); soit d'exactement 1 byte car rien n'empêche les bits de paddings. Tu es seulement assuré qu'il n'y en aura pas au début de la structure, et donc que l'adresse de a et l'adresse de ta structure sont les mêmes, comme dans toute structure en fait. C'est donc une commodité du langage pour representer les champs de bits.
De plus, savoir où sont les bits de poids fort ca dépend de ta convention et de ta machine (little endian, big endian...).
Anthony -- "I should have seen it would be this way I should have known from the start what she's up to When you have loved and you've lost someone You know what it feels like to lose" -- The Rasmus
Serge Paccalin
Le jeudi 12 février 2004 à 22:52, Zouplaz a écrit dans fr.comp.lang.c :
Bon, je suis pas certain de bien piger...
struct cafait8bits { unsigned int a :2; unsigned int b :2; unsigned int c :1; unsigned int d :3; };
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ?
Oui, quoiqu'un padding peut ajouter des octets à la suite.
Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Oui.
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Hé non, ça dépend de l'implantation choisie, ce qui limite l'intérêt de cette construction.
-- ___________ 2004-02-13 08:21:05 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Le jeudi 12 février 2004 à 22:52, Zouplaz a écrit dans fr.comp.lang.c :
Bon, je suis pas certain de bien piger...
struct cafait8bits {
unsigned int a :2;
unsigned int b :2;
unsigned int c :1;
unsigned int d :3;
};
Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ?
Oui, quoiqu'un padding peut ajouter des octets à la suite.
Et que sans ça il aurait fallu stocker le tout dans un unsigned char
et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Oui.
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Hé non, ça dépend de l'implantation choisie, ce qui limite l'intérêt de
cette construction.
--
___________ 2004-02-13 08:21:05
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Le jeudi 12 février 2004 à 22:52, Zouplaz a écrit dans fr.comp.lang.c :
Bon, je suis pas certain de bien piger...
struct cafait8bits { unsigned int a :2; unsigned int b :2; unsigned int c :1; unsigned int d :3; };
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ?
Oui, quoiqu'un padding peut ajouter des octets à la suite.
Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des >> pour décaler les bits afin de lire leur valeur ?
Oui.
Et dans cette struct, les bits de poids fort sont dans le membre a ?
Hé non, ça dépend de l'implantation choisie, ce qui limite l'intérêt de cette construction.
-- ___________ 2004-02-13 08:21:05 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Emmanuel Delahaye
In 'fr.comp.lang.c', Zouplaz wrote:
struct cafait8bits { unsigned int a :2; unsigned int b :2; unsigned int c :1; unsigned int d :3; };
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ?
Oui.
Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des
pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la norme. Ca dépend de l'implémentation. Ce n'est pas génant pour des structures internes. Mais certains se croient malins en faisant 'coller' une structure de bits sur du matériel (registres ou autre) ou des flux de données. Dommage, au moindre changement de compilateur ou de rélage, ça risque de ne plus fonctionner!
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Zouplaz <pouet@pouet.com> wrote:
struct cafait8bits {
unsigned int a :2;
unsigned int b :2;
unsigned int c :1;
unsigned int d :3;
};
Ca voudrait dire que cette struct représente un char (8 bits) avec la
possibilité d'accéder aux bits par groupe directement ?
Oui.
Et que sans ça
il aurait fallu stocker le tout dans un unsigned char et effectuer des
pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la norme.
Ca dépend de l'implémentation. Ce n'est pas génant pour des structures
internes. Mais certains se croient malins en faisant 'coller' une structure
de bits sur du matériel (registres ou autre) ou des flux de données. Dommage,
au moindre changement de compilateur ou de rélage, ça risque de ne plus
fonctionner!
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
struct cafait8bits { unsigned int a :2; unsigned int b :2; unsigned int c :1; unsigned int d :3; };
Ca voudrait dire que cette struct représente un char (8 bits) avec la possibilité d'accéder aux bits par groupe directement ?
Oui.
Et que sans ça il aurait fallu stocker le tout dans un unsigned char et effectuer des
pour décaler les bits afin de lire leur valeur ?
Et dans cette struct, les bits de poids fort sont dans le membre a ?
J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la norme. Ca dépend de l'implémentation. Ce n'est pas génant pour des structures internes. Mais certains se croient malins en faisant 'coller' une structure de bits sur du matériel (registres ou autre) ou des flux de données. Dommage, au moindre changement de compilateur ou de rélage, ça risque de ne plus fonctionner!
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Zouplaz
Emmanuel Delahaye - :
Et dans cette struct, les bits de poids fort sont dans le membre a ?
J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la norme. Ca dépend de l'implémentation. Ce n'est pas génant pour des structures internes. Mais certains se croient malins en faisant 'coller' une structure de bits sur du matériel (registres ou autre) ou des flux de données. Dommage, au moindre changement de compilateur ou de rélage, ça risque de ne plus fonctionner!
Ca explique que dans le header en question (c'est un header linux, je veux dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef pour prendre en compte l'endianess
Bon ceci dit, j'ai quand même appris un truc et c'est aussi plutôt pratique 'tte histoire !
Emmanuel Delahaye - emdelYOURBRA@noos.fr :
Et dans cette struct, les bits de poids fort sont dans le membre a ?
J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la
norme. Ca dépend de l'implémentation. Ce n'est pas génant pour des
structures internes. Mais certains se croient malins en faisant
'coller' une structure de bits sur du matériel (registres ou autre) ou
des flux de données. Dommage, au moindre changement de compilateur ou
de rélage, ça risque de ne plus fonctionner!
Ca explique que dans le header en question (c'est un header linux, je veux
dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef
pour prendre en compte l'endianess
Bon ceci dit, j'ai quand même appris un truc et c'est aussi plutôt pratique
'tte histoire !
Et dans cette struct, les bits de poids fort sont dans le membre a ?
J'ai vu les deux cas. L'emplacement des bits n'est pas spécifié par la norme. Ca dépend de l'implémentation. Ce n'est pas génant pour des structures internes. Mais certains se croient malins en faisant 'coller' une structure de bits sur du matériel (registres ou autre) ou des flux de données. Dommage, au moindre changement de compilateur ou de rélage, ça risque de ne plus fonctionner!
Ca explique que dans le header en question (c'est un header linux, je veux dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef pour prendre en compte l'endianess
Bon ceci dit, j'ai quand même appris un truc et c'est aussi plutôt pratique 'tte histoire !
Moi
Dans l'article écrivait :
Ca explique que dans le header en question (c'est un header linux, je veux dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef pour prendre en compte l'endianess
Pas du tout, c'est dans /usr/include/netinet/tcp.h On trouve le même sur les BSD (enfin c'est le contraire)
D'ailleurs yaka regarder le Copyright et se souvenir qui a foutu TCP/IP dans Unix.
Dans l'article <Xns948F75E1B957FZoupla@212.27.42.66>
pouet@pouet.com écrivait :
Ca explique que dans le header en question (c'est un header linux, je veux
dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef
pour prendre en compte l'endianess
Pas du tout, c'est dans /usr/include/netinet/tcp.h
On trouve le même sur les BSD (enfin c'est le contraire)
D'ailleurs yaka regarder le Copyright et se souvenir qui a foutu
TCP/IP dans Unix.
Ca explique que dans le header en question (c'est un header linux, je veux dire /usr/include/linux) l'auteur en délivre deux versions à coup de #ifdef pour prendre en compte l'endianess
Pas du tout, c'est dans /usr/include/netinet/tcp.h On trouve le même sur les BSD (enfin c'est le contraire)
D'ailleurs yaka regarder le Copyright et se souvenir qui a foutu TCP/IP dans Unix.
