C/C++ 结构体的一个高级特性 ―― 指定成员的位数

在大多数情况下，我们一般这样定义结构体：
struct student
{
unsigned int sex;
unsigned int age;
};
对于一般的应用，这已经能很充分地实现数据了的 “ 封装 ” 。
但是，在实际工程中，往往碰到这样的情况：那就是要用一个基本类型变量中的不同的位表示不同的含义。譬如一个 cpu 内部的标志寄存器，假设为 16 bit ，而每个 bit 都可以表达不同的含义，有的表示结果是否为 0 ，有的表示是否越界等等。这个时候我们用什么数据结构来表达这个寄存器呢？
答案还是结构体！
为达到此目的，我们要用到结构体的高级特性，那就是在基本成员变量的后面添加“ : 数据位数”组成新的结构体：
struct xxx
{
成员 1 类型成员 1 : 成员 1 位数 ;
成员 2 类型成员 2 : 成员 2 位数 ;
成员 3 类型成员 3 : 成员 3 位数 ;
};
基本的成员变量就会被拆分！这个语法在初级编程中很少用到，但是在高级程序设计中不断地被用到！例如：
struct student
{
unsigned int sex : 1;
unsigned int age : 15;
};
上述结构体中的两个成员 sex 和 age 加起来只占用了一个 unsigned int 的空间（假设 unsigned int 为 16 位）。
基本成员变量被拆分后，访问的方法仍然和访问没有拆分的情况是一样的，例如：
struct student sweek;
sweek.sex = MALE;// 这里的 MALE 只能是 0 或 1 ，值不能大于 1
sweek.age = 20;
虽然拆分基本成员变量在语法上是得到支持的，但是并不等于我们想怎么分就怎么分，例如下面的拆分显然是不合理的：
struct student
{
unsigned int sex : 1;
unsigned int age : 12;
};
这是因为 1+12 = 13 ，不能再组合成一个基本成员，不能组合成 char 、 int 或任何类型，这显然是不能 “ 自圆其说 ” 的。
在拆分基本成员变量的情况下，我们要特别注意数据的存放顺序，这还与 CPU 是 Big endian 还是 Little endian 来决定。 Little endian 和 Big endian 是 CPU 存放数据的两种不同顺序。对于整型、长整型等数据类型， Big endian 认为第一个字节是最高位字节（按照从低地址到高地址的顺序存放数据的高位字节到低位字节）；而 Little endian 则相反，它认为第一个字节是最低位字节（按照从低地址到高地址的顺序存放数据的低位字节到高位字节）。
我们定义 IP 包头结构体为：
struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8 ihl:4,
version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
__u8 version:4,
ihl:4;
#else
#error "Please fix <asm/byteorder.h>"
#endif
__u8 tos;
__u16 tot_len;
__u16 id;
__u16 frag_off;
__u8 ttl;
__u8 protocol;
__u16 check;
__u32 saddr;
__u32 daddr;
/*The options start here. */
};
在 Little endian 模式下， iphdr 中定义：
__u8 ihl:4,
version:4;
其存放方式为：
第 1 字节低 4 位 ihl
第 1 字节高 4 位 version （ IP 的版本号）
若在 Big endian 模式下还这样定义，则存放方式为：
第 1 字节低 4 位 version （ IP 的版本号）
第 1 字节高 4 位 ihl
这与实际的 IP 协议是不匹配的，所以在 Linux 内核源代码中， IP 包头结构体的定义利用了宏：
#if defined(__LITTLE_ENDIAN_BITFIELD)
…
#elif defined (__BIG_ENDIAN_BITFIELD)
…
#endif
来区分两种不同的情况。
由此我们总结全文的主要观点：
（ 1 ） C/C++ 语言的结构体支持对其中的基本成员变量按位拆分；
（ 2 ） 拆分的位数应该是合乎逻辑的，应仍然可以组合为基本成员变量；
要特别注意拆分后的数据的存放顺序，这一点要结合具体的 CPU 的结构。

该文是由宋宝华处转载而来的，笔者以前从未知道结构体还可以这样用法，笔者做过尝试，再 VC 下用过的感受有两点
1、 结构体按位拆分时，虽然宋兄提醒不能拆分如文中红色背景显示的情况，但是本人试过，并非是不可以的，而且如果 CPU 支持 32 的话，显然文中的以 16 位来分配的话也是没有达到要求的。
2、 按位拆分时字节数目问题，我们先看两例
struct student1
{
unsigned char sex : 1;
unsigned int no : 5;
char age : 7;
int grade : 10;
};

struct student2
{
unsigned char sex : 1;
char age : 7;
unsigned int no : 5;
int grade : 10;
};
以上两例中虽然意思并不大，但是如果按 int 为 2 字节 16 位 char 为 1 字节 8 位来划分内存的话，那么 student1 占用了 6 字节共 48 位，但是实际使用了 23 位，另外 25 位没定义，而 student2 占用了 3 字节共 24 位，但是实际使用也是 23 位。这个过程，我把它总结为前后变量的类型不一致时，字节就重新分配。
3、 赋值过程中数据编码问题。还看两例
student1 ss;
ss.age = 255;
student2 st;
st.age= 191;
ss.age 的值为 -1 ，而 st.age 的值为 63 ，其实 255 为 11111111 ，因为是 7 位，所以采用截断方式，变成 1111111 ，又因为 age 是有符号的变量，所以根据负数的编码规则赋值 255 时得到的结果就是 -1 。在这里采用了截断的方式，为止正确赋值时一定不能大于位数编码值。