Champ de bits de manipulation en C

Si le problème est que l'établissement et la compensation de bits est sujette aux erreurs, puis la bonne chose à faire est d'écrire des fonctions ou macros assurez-vous que vous le faites à droite.

//off the top of my head
#define SET_BIT(val, bitIndex) val |= (1 << bitIndex)
#define CLEAR_BIT(val, bitIndex) val &= ~(1 << bitIndex)
#define TOGGLE_BIT(val, bitIndex) val ^= (1 << bitIndex)
#define BIT_IS_SET(val, bitIndex) (val & (1 << bitIndex)) 

Qui rend votre code lisible si vous n'avez pas l'esprit que val a à être une lvalue, sauf pour BIT_IS_SET. Si cela ne vous rend pas heureux, alors vous prenez affectation, parenthesize et de les utiliser comme val = SET_BIT(val, someIndex); qui sera l'équivalent.

Vraiment, la réponse est à considérer découplage de la ce que vous voulez de la façon dont vous voulez le faire.

Vous avez à penser à ce sujet dans le point de vue d'un écrivain -- connaître votre public. Donc, il ya un couple de "publics" à prendre en compte.

D'abord il y a le classique programmeur C, qui ont bitmasked toute leur vie et pourrait le faire dans leur sommeil.

Deuxième il y a le newb, qui n'a aucune idée de ce que tout cela,|, & truc est. Ils ont été de programmation php à leur travail, et maintenant ils travaillent pour vous. (Je dis cela comme un newb qui n'php)

Si vous écrivez pour satisfaire à la première audience (c'est-masque-tous-journée), vous allez les rendre très heureux, et ils vont être en mesure de maintenir le code, les yeux bandés. Cependant, le newb aurez probablement besoin de surmonter une grande courbe d'apprentissage avant qu'ils ne soient en mesure de maintenir votre code. Ils auront besoin d'apprendre sur les opérateurs binaires, la façon dont vous utilisez ces opérations à définir/effacer les bits, etc. Vous êtes presque certainement allez avoir des bugs introduits par la newb comme il/elle toutes les astuces nécessaires pour obtenir que cela fonctionne.

D'autre part, si vous écrivez à satisfaire à la seconde audience, les newbs aurez un temps plus facile de maintenir le code. Ils ont un temps plus facile de groking

 flags.force = 0;

que

 flags &= 0xFFFFFFFE;

et la première audience aura juste grognon, mais il est difficile d'imaginer qu'ils ne serait pas en mesure d'analyser et de maintenir la nouvelle syntaxe. C'est juste beaucoup plus difficile à visser. Il n'y aura pas de nouveaux bugs, parce que le newb sera plus facile de maintenir le code. Il vous suffit de faire des conférences sur comment "de retour dans ma journée vous avez besoin d'une main ferme et d'une aiguille magnétisée pour définir les bits... nous n'avons même pas de masques de bits!" (merci XKCD).

Donc, je voudrais vous recommandons vivement d'utiliser les champs sur les masques de bits de newb-sûr de votre code.

Ce que c'est sur le champ de bits approche qui vous fait grincer des dents?

Les deux techniques ont leur place, et la seule décision que j'ai, c'est celui à utiliser:

Pour un simple "one-off" peu tripoter, j'utilise les opérateurs au niveau du bit directement.

Pour quelque chose de plus complexe - par exemple matériel de registre des cartes, le champ de bits approche gagne haut la main.

• Bitfields sont plus succincts à utiliser
  (au détriment de /un peu/plus d'
  le niveau de verbosité à écrire.
• Bitfields sont
  plus robuste (quelle est la taille de "int",
  de toute façon)
• Bitfields sont habituellement juste
  aussi vite que les opérateurs sur les bits.
• Bitfields sont très puissant lorsque vous
  un mélange d'un seul ou de plusieurs bits
  les champs, et l'extraction de la
  plusieurs bits de terrain implique des charges de
  manuel de quarts de travail.
• Bitfields sont
  effectivement l'auto-documentation. Par
  la définition de la structure et donc
  nommer les éléments, je sais ce que c'est
  censé faire.
• Bitfields aussi parfaitement manipuler des structures de plus grande qu'un simple int.

• Avec les opérateurs au niveau du bit, typique (bad) est la pratique d'un grand nombre de #définit pour les masques de bits.

• Le seul inconvénient avec bitfields est de s'assurer que le compilateur a vraiment emballé l'objet dans la taille que vous vouliez. Je ne me souviens pas si c'est définir par la norme, donc un assert(sizeof(myStruct) == N) est utile pour vérifier.

La post de blog vous référer aux mentions raw de l'union de champ en tant que variante de la méthode d'accès pour bitfields.

Les fins d'après le blog de l'auteur utilisé raw sont ok, mais si vous prévoyez de l'utiliser pour autre chose (par exemple, la sérialisation des champs de bits, réglage/vérification des bits individuels), la catastrophe est juste en attente pour vous, dans le coin. L'ordre des bits dans la mémoire est dépendants de l'architecture et de la mémoire rembourrage règles varient d'un compilateur de compilateur (voir wikipédia), de sorte que la position exacte de chaque champ de bits peut diffère, en d'autres termes, vous ne pouvez être sûr de bits de raw chaque champ de bits correspond à.

Toutefois, si vous ne prévoyez pas de le mélanger à mieux vous prendre raw et vous serez en sécurité.

En C++, il suffit d'utiliser std::bitset<N>.

Votre première méthode est préférable, à mon humble avis. Pourquoi occulter la question? Peu tripoter est vraiment une chose fondamentale. C le fait correctement. Endianess n'a pas d'importance. La seule chose que l'union de la solution n'est de nommer les choses. 11 pourrait être mystérieux, mais #défini par un nom significatif ou enum ed devrait suffire.

Programmeurs qui ne peut pas gérer les fondamentaux comme "|&^~" sont probablement dans la mauvaise ligne de travail.

J'ai presque toujours utiliser les opérations logiques avec un masque de bits, soit directement, soit sous forme d'une macro. par exemple,

 #define  ASSERT_GPS_RESET()                    { P1OUT &= ~GPS_RESET ; }

d'ailleurs votre union définition dans la question d'origine ne fonctionnerait pas sur mon processeur/compilateur combinaison. Le type int est que de 16 bits de large et le champ de bits définitions sont 32. Afin de le rendre plus portable alors que vous auriez à définir un nouveau 32 bits de type que vous pouvez ensuite la carte à la base de type sur chaque cible de l'architecture dans le cadre du portage de l'exercice. Dans mon cas,

typedef   unsigned long int     uint32_t

et dans l'exemple original

typedef unsigned int uint32_t

typedef union {
        struct {
                boolean_t user:1;
                boolean_t zero:1;
                boolean_t force:1;
                int :28;                /* unused */
                boolean_t compat:1;     /* bit 31 */
        };
        uint32_t raw;
} flags_t;

La superposition de l'int doit également être faite non signé.

En général, celui qui est plus facile à lire et à comprendre est celui qui est également plus facile à maintenir. Si vous avez des collègues qui sont nouveaux à C, la plus "sécuritaire" approche sera probablement le plus facile pour eux de comprendre.