Discussion :

[ali.ensi]

Bonjour,

Je viens de rencontrer une déclaration en C que je vois pour la première fois et que je comprends pas.
La déclaration est la suivante :

-------------Exemple de code--------------------
struct foo {
signed char x: 2;
unsigned char : 1; /* pour l'alignement */
signed char y: 3;
signed char z: 2;
};
-------------------------------------------------

Ce qui est nouveau pour moi, ce sont les ": x" qu'on met à la fin de chaque ligne de la struct?

Quelqu'un peut-il m'éclairer ?

[Médinoc]

Il s'agit de champs de bits: On indique quel nombre de bits prend chaque champ de la structure.

Sauf que ça ne sert pratiquement à rien parce que l'implémentation n'est pas portable: Rien dans la norme ne te garantit l'ordre des différents champs d'une telle structure, tout dépend de l'implémentation.

[ali.ensi]

Mais à quoi sert de déterminer le nombre de bits que chaque champ de la structure doit prendre étant donné que on a déjà défini un type pour chaque champ et que chque type a une taille fixe du genre, un char sera codé sur un octet (voire 2 octets chépa... ).

Si je déclare un char de la sorte

============Exemple de code====================
....
unsigned char x : 2;
....
=============================================

Est-ce que dans ce cas x sera codé sur 2 bits ou bien sur un octet vu que c'est un char ?

[diogene]

Est-ce que dans ce cas x sera codé sur 2 bits ou bien sur un octet vu que c'est un char ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

unsigned char x : 2;

x sera codé dans la structure sur 2 bits .
Mais pour l'accès à ce champ, sa valeur sera convertie en un unsigned char.
Autrement dit, en interne à la structure, il occupe 2 bits et vu de l'extérieur de la structure c'est un unsigned char.

[pfeuh]

Salut,

l'implémentation n'est pas portable: Rien dans la norme ne te garantit l'ordre des différents champs d'une telle structure, tout dépend de l'implémentation.

Veux tu dire que dans l'exemple ci dessous, la valeur de JOYSTICK_KEY_UP n'est pas garantie? C'est une façon de faire que j'utilise souvent sans avoir constaté de problème.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#define JOYSTICK_NO_KEY       0x00
#define JOYSTICK_KEY_UP       0x01
#define JOYSTICK_KEY_DOWN     0x02
#define JOYSTICK_KEY_RIGHT    0x04
#define JOYSTICK_KEY_LEFT     0x08
#define JOYSTICK_KEY_FIRE     0x10
 
typedef unsigned char UByte;
 
typedef union
{
    UByte allbits;
    struct
    {
        UByte up:1;
        UByte down:1;
        UByte right:1;
        UByte left:1;
        UByte fire:1;
        UByte dummy:3;
    };
}JOYSTICK_Register;

A+

Pfeuh

[Médinoc]

Salut,

Veux tu dire que dans l'exemple ci dessous, la valeur de JOYSTICK_KEY_UP n'est pas garantie? C'est une façon de faire que j'utilise souvent sans avoir constaté de problème.

C'est exactement ce que je veux dire. Ça peut être garanti par certaines plate-formes ou certains compilateurs, mais ça n'est pas garanti par la norme.

[Melem]

Il s'agit de champs de bits: On indique quel nombre de bits prend chaque champ de la structure.

Sauf que ça ne sert pratiquement à rien parce que l'implémentation n'est pas portable: Rien dans la norme ne te garantit l'ordre des différents champs d'une telle structure, tout dépend de l'implémentation.

Ca peut toujours servir à économiser de la mémoire . Mais je suis d'accord, il faut être maniac pour ça. De plus, unsigned char : x c'est déjà pas portable. La norme dit que pour créer des données de taille spécifiée en bits, il faut utiliser un int, signed ou unsigned. Mais une implémentation peut (c'est précisé par la norme) supporter d'autres types (comme unsigned char ...).

[ram-0000]

Je pense que les champs de bits ont été inventés pour permettre aux développeurs de se coller exactement avec les composants électroniques.

Car les électroniciens eux sont (ou tout au moins étaient) avares de la mémoire.

Par exemple, sur le circuit de gestion du port parallèle, il y a 4 ou 5 flags qui remontent sur un seul registre de 8 bits. La notion de champs de bits permet dans ce cas d'accèder directement au flag voulu sans avoir à s'embêter avec des masques de bits.

L'autre possibilité, c'est justement d'utiliser les masque de bits mais bon.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if((value & 0x80) == 0x80) // par exemple

[Médinoc]

Je pense que les champs de bits ont été inventés pour permettre aux développeurs de se coller exactement avec les composants électroniques.

Car les électroniciens eux sont (ou tout au moins étaient) avares de la mémoire.

Par exemple, sur le circuit de gestion du port parallèle, il y a 4 ou 5 flags qui remontent sur un seul registre de 8 bits. La notion de champs de bits permet dans ce cas d'accèder directement au flag voulu sans avoir à s'embêter avec des masques de bits.

C'est ce qui parait logique, mais si ça avait été le cas, ça aurait été normalisé, non?