Bit field

c 语言中的bit field 是一种节省内存的方式， 用于struct 或者 union 的成员变量的声明。基本的语法是：

struct BF {   ...  type_specifier [declarator] : constant_expression;   ...};

采用这样一种方式的好处是，我们可以明确地指定某一个成员变量在内存中占用的空间(constant_expression bits). 比如：

struct BitArray {    unsigned a : 1;    unsigned b : 1;};// sizeof(BitArray) == 4struct BitArray2{    unsigned a;    unsigned b;};// sizeof(BitArray2) == 8

上面的例子可以看出，使用了Bit field, 我们可以将相邻的变量a 和 b 紧凑的排列到一个unsigned 中。 而如果不适用Bit field, 很明显编译器将会单独为a 和 b 创建一个 unsigned 成员变量。

但是在使用bit field的时候，我们发现有很多限制或者注意点，这里罗列出大部分可能会碰到的问题。

• 底层数据类型
  bit field 本身不是C/C++的基本类型，需要依附于底层数据在内存中的表示。一般多个bit fields 会共享一个底层数据类型所占用的内存空间。 底层类型只能是整形(char, short, int, long, long long 和 unsigned 变种） 或者枚举类型（enum ) :

enum E { E1, E2, E3, E4, E5, E6 = 200 };struct SMixture {    char a : 1, b : 1 ; //ok    E e1 : 2,  e2 : 2;  //ok    float f : 3 ;       //compiler error};

• 如果底层类型大小不足以容纳所有的 bit fields, 则在内存中开辟新的底层数据类型以容纳更多的域，但是多余的域不会横跨相邻的底层数据空间，而是开辟新的空间开始放置多余的Bit fields.

struct SMixture {    char a : 1;  //start of first char    char b : 3;  //continue in the first char    char c : 5;  //start of second char    char d : 4;  //start of third char};// sizeof(SMixture) == 3;

• 匿名域(unnamed bit field)起padding的作用。 如果域的大小为0，则必须匿名（unnamed ).

struct SMixture {   char c : 1;   char d : 0; //compiler error   char : 0;   //okay};

width 为0的域是特殊域，表示该0-width bit field的下一个成员的地址必须以该0-width bit field 的类型的对齐方式对齐。

struct SMixture {   char c : 1;   //start of char   int : 0;   short d : 1;   //start of short after alignment at type int boundary};//sizeof(SMixture) == 6;struct SMixture2 {   char c : 1;   //start of char   int : 0;   short d;   //start of short after alignment at type int boundary};//sizeof(SMixture2) == 6

• 不能通过地址操作符(&)获取bit field的地址，因此bit field不能通过指针访问, 也不能通过引用访问。

int main(){    SMixture s;    short* ps = &s.d; //compiler error    short& rs = s.d;  //compiler error    return 0;}

• Bit field 不能是 static 成员。

struct SMixture {   static char c : 1;   //compiler error};

• 使用bit field 的初衷是为了节省内存的消耗，但是最终的结果可能事与愿违。虽然bit field一定会减少类型的数据空间， 但是为了进行比特位操作，编译器不得不在生成的代码中加入额外的控制代码。因此最终的代码有可能比不使用bit field的情形还要大。另外一方面，直接访问整型数据类型一定会比访问bit fields要快。因此，在代码中使用bit field的情形可能相当有限。比如， 在这篇stackoverflow的文章中提到跨平台或者硬件的二进制文件的兼容问题，此时可能需要将某些成员变量强制对齐到某个位置：

/* from xnu/bsd/netinet/bootp.h *//* * Bootstrap Protocol (BOOTP).  RFC 951. *//* * HISTORY * * 14 May 1992 ? at NeXT *  Added correct padding to struct nextvend.  This is *  needed for the i386 due to alignment differences wrt *  the m68k.  Also adjusted the size of the array fields *  because the NeXT vendor area was overflowing the bootp *  packet. *//* . . . */struct nextvend {  u_char nv_magic[4]; /* Magic number for vendor specificity */  u_char nv_version;  /* NeXT protocol version */  /*   * Round the beginning   * of the union to a 16   * bit boundary due to   * struct/union alignment   * on the m68k.   */  unsigned short  :0;  union {    u_char NV0[58];    struct {      u_char NV1_opcode;  /* opcode - Version 1 */      u_char NV1_xid; /* transcation id */      u_char NV1_text[NVMAXTEXT]; /* text */      u_char NV1_null;  /* null terminator */    } NV1;  } nv_U;};