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 。在这里采用了截断的方式,为止正确赋值时一定不能大于位数编码值。

 使用位域的主要目的是压缩存储,其大致规则为:
1) 如果相邻位域字段的类型相同,且其位宽之和小于类型的sizeof大小,则后面的字段将紧邻前一个字段存储,直到不能容纳为止;
2) 如果相邻位域字段的类型相同,但其位宽之和大于类型的sizeof大小,则后面的字段将从新的存储单元开始,其偏移量为其类型大小的整数倍;
3) 如果相邻的位域字段的类型不同,则各编译器的具体实现有差异,VC6采取不压缩方式,Dev-C++采取压缩方式;
4) 如果位域字段之间穿插着非位域字段,则不进行压缩;
5) 整个结构体的总大小为最宽基本类型成员大小的整数倍。