[转寄/推荐][转贴][删除][修改][设置可RE属性][上一篇][返回讨论区][下一篇][回文章][同主题列表][同主题阅读][从这里展开]
发信人: gaobo(狄立赫列), 信区: C 标 题: 【合集】一个困扰我的笔试题，关于位域，请教 发信站: 饮水思源 (2007年06月26日22:09:41 星期二), 站内信件 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日11:53:44 星期二) 提到： #include <stdio.h> void main() { union { struct { unsigned short s1:3; unsigned short s2:3; unsigned short s3:3; }x; char c; }v; v.c=100; printf("%d\n",v.x.s3); } A:4 B:0 C:3 D:6 不是应该这样吗 ： 如果位序是高位放低地址，低位放高地址 （通常big endian字节序会有这样的位序） bit0~bit7为0110 0100 则s1为011，s2为001，s3为000（已经在下一个字节了）即0 －－－－－－－－－－－－ 如果位序是高位放高地址，低位放低地址 （通常little endian字节序会有这样的位序） bit0~bit7为0010 0110 则s1为001，s2为001，s3为100（已经在下一个字节了）即4 请问这样解释有什么问题吗？ 请知道的牛牛说说怎么回事，谢谢。 ☆──────────────────────────────────────☆ netbsd (Bill Joy) 于 2007年06月05日12:41:52 星期二 提到： alignment? 【 在 wuxuemin (FanLisa) 的大作中提到: 】 : #include <stdio.h> : void main() : { : union : { : struct : { : unsigned short s1:3; : unsigned short s2:3; : unsigned short s3:3; : .................（以下省略） ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日12:52:15 星期二) 提到： 大数端小数端仅关乎字节之间的顺序 c只有一个字节 v.c=100在内存中总是0110 0100 对应s3 s2 s1 s1 100 s2 100 s3 01 【 在 wuxuemin 的大作中提到: 】 : #include <stdio.h> : void main() : { : union : { : struct : { : unsigned short s1:3; : unsigned short s2:3; : unsigned short s3:3; : }x; : char c; : }v; : v.c=100; : printf("%d\n",v.x.s3); : } : A:4 B:0 C:3 D:6 : 不是应该这样吗 ： : 如果位序是高位放低地址，低位放高地址 : （通常big endian字节序会有这样的位序） : (以下引言省略...) ☆──────────────────────────────────────☆ skys (幻灭) 于 2007年06月05日12:55:56 星期二 提到： 是这样的 嵌入式开发中 采用Little-endian模式的CPU对操作数的存放方式是从低字节到高字节，而Big-endian 模式对操作数的存放方式是从高字节到低字节。 【 在 wuxuemin (FanLisa) 的大作中提到: 】 : #include <stdio.h> : void main() : { : union : { : struct : { : unsigned short s1:3; : unsigned short s2:3; : unsigned short s3:3; : .................（以下省略） ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日13:45:05 星期二) 提到： 【 在 CSgtree 的大作中提到: 】 : 大数端小数端仅关乎字节之间的顺序 : c只有一个字节 : v.c=100在内存中总是0110 0100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 字节内部的“比特序”不是通常和“字节序”一致 吗？那在little endian时就应该是0010 0110吧 : 对应s3 s2 s1 : s1 100 : s2 100 : s3 01 ~~~~~~~~~~不是说“ANSI C要求在struct里面，先声明的成员占有低地址”吗？ : (以下引言省略...) ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日13:52:09 星期二) 提到： 输出结果会是什么？ 【 在 skys 的大作中提到: 】 : 是这样的 : 嵌入式开发中 : 采用Little-endian模式的CPU对操作数的存放方式是从低字节到高字节，而Big-endian : 模式对操作数的存放方式是从高字节到低字节。 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日14:03:59 星期二) 提到： 都bit field了就无所谓alignment吧？ 在字节剩余的位空间不足够放下下一个位域的时候 从下一单元放起该位域就可以了吧 【 在 netbsd 的大作中提到: 】 : alignment? ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日14:19:43 星期二) 提到： 又查过些资料，觉得你的说法不太对。 【 在 CSgtree 的大作中提到: 】 : 大数端小数端仅关乎字节之间的顺序 : c只有一个字节 : v.c=100在内存中总是0110 0100 : 对应s3 s2 s1 : s1 100 : s2 100 : s3 01 : (以下引言省略...) ☆──────────────────────────────────────☆ Magiiii (Magi... (不会读的同学请查字典) 于 2007年06月05日14:30:18 星期二) 提到： v.c=100在大数端和小数端都是0110 0100，仅在int内的字节序有差异 不过我认为 s1 011 s2 100 s3 000 【 在 wuxuemin 的大作中提到: 】 : 又查过些资料，觉得你的说法不太对。 ☆──────────────────────────────────────☆ liuxueshen (firerock) 于 2007年06月05日14:40:45 星期二 提到： 可是…… 他的结构是：3、3、3，有9位啊 【 在 CSgtree (w_ch) 的大作中提到: 】 : 标 题: Re: 一个困扰我的笔试题，关于位域，请教 : 发信站: 饮水思源 (2007年06月05日12:52:15 星期二) : : 大数端小数端仅关乎字节之间的顺序 : c只有一个字节 : v.c=100在内存中总是0110 0100 : 对应s3 s2 s1 : s1 100 : s2 100 : s3 01 : : -- : : ※ 来源:·饮水思源 bbs.sjtu.edu.cn·[FROM: 121.248.16.98] : : ※ 修改内容:·CSgtree 于 06月05日13:11:40 修改本文·[FROM: 211.65.235.90] ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日14:41:25 星期二) 提到： 查了一下 应该要考虑位序 大概是这样的//不确定 大数端表示 0110 0100（位序从左到右递增） s1 s2 s3依次从低位序取到高位序处 即011,001,000 分别为3 1 0 －－－－－－－－－－－－ 小数端表示 0010 0110（位序从左到右递增） s1 s2 s3依次从低位序取到高位序处 则s1为001，s2为001，s3为100 但是考虑到小数端对位序的解释（例如4=0000 0100存储为0010 0000） s1=001实际表示100=4 故分别为4 4 1 【 在 wuxuemin 的大作中提到: 】 : 又查过些资料，觉得你的说法不太对。 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日14:44:43 星期二) 提到： 对，这个要跨字节，放不下的位域要从下个字节再开始存储 【 在 liuxueshen 的大作中提到: 】 : 可是…… : 他的结构是：3、3、3，有9位啊 ☆──────────────────────────────────────☆ liuxueshen (firerock) 于 2007年06月05日14:44:44 星期二 提到： 这只是针对4位机系统的吧。 我在作与西门子PLC通讯的时候， 西门子用的位序跟PC是不同的， 只要按照字节（8位）依次转换就可以了。 【 在 CSgtree (w_ch) 的大作中提到: 】 : 标 题: Re: 一个困扰我的笔试题，关于位域，请教 : 发信站: 饮水思源 (2007年06月05日14:41:25 星期二) : : 查了一下 : 应该要考虑位序 : 大概是这样的//不确定 : : 大数端表示 : 0110 0100（位序从左到右递增） : s1 s2 s3依次从低位序取到高位序处 : 即011,001,000 : 分别为3 1 0 : －－－－－－－－－－－－ : 小数端表示 : 0010 0110（位序从左到右递增） : s1 s2 s3依次从低位序取到高位序处 : 则s1为001，s2为001，s3为100 : 但是考虑到小数端对位序的解释（例如4=0000 0100存储为0010 0000） : s1=001实际表示100=4 : 故分别为4 4 1 : : -- : : ※ 来源:·饮水思源 bbs.sjtu.edu.cn·[FROM: 211.65.234.94] ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日15:05:54 星期二) 提到： 【 在 CSgtree 的大作中提到: 】 : 查了一下 : 应该要考虑位序 : 大概是这样的//不确定 : 大数端表示 : 0110 0100（位序从左到右递增） : s1 s2 s3依次从低位序取到高位序处 : 即011,001,000 : 分别为3 1 0 : －－－－－－－－－－－－ : 小数端表示 : 0010 0110（位序从左到右递增） : s1 s2 s3依次从低位序取到高位序处 : 则s1为001，s2为001，s3为100 : 但是考虑到小数端对位序的解释（例如4=0000 0100存储为0010 0000） ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这里请详细说说，第一次听到这个 : s1=001实际表示100=4 : 故分别为4 4 1 ~~~~~~~~~~~~~~~~~~（别人在VC跑的结果S3确实就是1) ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日15:16:30 星期二) 提到： 就是说001是机器中的表示 因为位序从左到右递增 而对小数端而言 高位序处表示实际数据的高位 这个和小数端的字节序的解释类似的 【 在 wuxuemin 的大作中提到: 】 : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这里请详细说说，第一次听到这个 : ~~~~~~~~~~~~~~~~~~（别人在VC跑的结果S3确实就是1) ☆──────────────────────────────────────☆ Magiiii (Magi... (不会读的同学请查字典) 于 2007年06月05日15:44:00 星期二) 提到： 不对，位序是不变的，一直01100100 但是对于小数端 0|01 100 100 s3 s2 s1 因此s3=1，s从低地址分配到高地址 【 在 CSgtree 的大作中提到: 】 : 就是说001是机器中的表示 : 因为位序从左到右递增 : 而对小数端而言 : 高位序处表示实际数据的高位 : 这个和小数端的字节序的解释类似的 ☆──────────────────────────────────────☆ liuxueshen (firerock) 于 2007年06月05日16:00:53 星期二 提到： 刚刚试了下： 把unsigned short 替换成unsigned char 最后一个变0了…… 【 在 Magiiii (Magi... (不会读的同学请查字典) 的大作中提到: 】 : 标 题: Re: 一个困扰我的笔试题，关于位域，请教 : 发信站: 饮水思源 (2007年06月05日15:44:00 星期二) : : 不对，位序是不变的，一直01100100 : 但是对于小数端 : 0|01 100 100 : s3 s2 s1 : 因此s3=1，s从低地址分配到高地址 : : : : -- : : ※ 来源:·饮水思源 bbs.sjtu.edu.cn·[FROM: 202.120.38.223] ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日16:19:23 星期二) 提到： 那你的意思是(以下都不考虑跨字节）: little和big endian的bit0~7都是0110 0100不变 1. 小端的位域的赋值顺序和字节序为： 从右到左赋值（即从低位到高位) 2. 大端的位域的赋值顺序和字节序为： 从左到右赋值 (即从高位到低位） 所以 little endian的S1＝100，S2=100，S3＝001 bit endian 的S1＝011，S2=001，S3＝000 right? 但是答案是s3＝4 _-_! 【 在 Magiiii 的大作中提到: 】 : 不对，位序是不变的，一直01100100 : 但是对于小数端 : 0|01 100 100 : s3 s2 s1 : 因此s3=1，s从低地址分配到高地址 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日16:22:19 星期二) 提到： 难道你的机子是big endian的？比如MAC的。 PS,unsigned short 为啥要换？ 【 在 liuxueshen 的大作中提到: 】 : 刚刚试了下： : 把unsigned short 替换成unsigned char : 最后一个变0了…… ☆──────────────────────────────────────☆ justicezyx (just) 于 2007年06月05日18:29:46 星期二) 提到： 我琢磨了一下,这题跟大小端无关.而是在于字节内的比特位序. 0------7 or 7------0 ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日18:51:10 星期二) 提到： 原本我也这样觉得 但是查阅资料说 字节序与比特序是一致的 对于大小数端是不同的 我机器上的结果是4 4 1 在同学mac上是3 1 1 【 在 Magiiii 的大作中提到: 】 : 不对，位序是不变的，一直01100100 : 但是对于小数端 : 0|01 100 100 : s3 s2 s1 : 因此s3=1，s从低地址分配到高地址 ☆──────────────────────────────────────☆ Magiiii (Magi... (不会读的同学请查字典) 于 2007年06月05日20:17:24 星期二) 提到： 其实这里的区别主要在于struct位段从低地址开始分配还是从高地址开始分配，而不是大 小数端，我觉得大小数端应该是在字节序而不是比特序，当然这也是一个定义的问题。 而且这题和编译器非常相关 所以总结下来此题的结果和系统太相关了，标准答案基本是错的 顺便付我找到的CSDN的帖： http://topic.csdn.net/t/20050904/12/4248520.html pc上面是1，powerpc上面是0(vc6.0,windowsxp)， pc上面是：100, 100, 001 ( 001100100 = 100 ) ,低位放在低内存 powerpc上面是：011，001，000（01100100 = 100 )，高位放前面(codewarri or + macosx) powerpc上面运行结果是：0， pc上面运行结果是1 【 在 CSgtree 的大作中提到: 】 : 原本我也这样觉得 : 但是查阅资料说 : 字节序与比特序是一致的 : 对于大小数端是不同的 : 我机器上的结果是4 4 1 : 在同学mac上是3 1 1 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日20:39:14 星期二) 提到： 【 在 Magiiii 的大作中提到: 】 : 其实这里的区别主要在于struct位段从低地址开始分配还是从高地址开始分配，而不.. : 小数端，我觉得大小数端应该是在字节序而不是比特序，当然这也是一个定义的问题。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~大小端确实就是字节间的序 : 而且这题和编译器非常相关 : 所以总结下来此题的结果和系统太相关了，标准答案基本是错的 : 顺便付我找到的CSDN的帖： : http://topic.csdn.net/t/20050904/12/4248520.html : pc上面是1，powerpc上面是0(vc6.0,windowsxp)， : pc上面是：100, 100, 001 ( 001100100 = 100 ) ,低位放在低�.. : : powerpc上面是：011，001，000（01100100 = 100 )，高位放前面(codew.. : or + macosx) : : powerpc上面运行结果是：0， ~~~~~~~~~~~~~~这个和MAC应该是相同的吧，但上面 CSgtree同学的MAC事实是1 : pc上面运行结果是1 ~~~~~~~~~~~~~~~~~这个大家都一致 : (以下引言省略...) ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日20:39:41 星期二) 提到： 【 在 Magiiii 的大作中提到: 】 : 其实这里的区别主要在于struct位段从低地址开始分配还是从高地址开始分配，而不.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 我觉得这个的本质就是比特序的不同 struct应该总是从低位开始分配的 : 小数端，我觉得大小数端应该是在字节序而不是比特序，当然这也是一个定义的问题。 : 而且这题和编译器非常相关 : 所以总结下来此题的结果和系统太相关了，标准答案基本是错的 : 顺便付我找到的CSDN的帖： : http://topic.csdn.net/t/20050904/12/4248520.html : pc上面是1，powerpc上面是0(vc6.0,windowsxp)， : pc上面是：100, 100, 001 ( 001100100 = 100 ) ,低位放在低�.. : : powerpc上面是：011，001，000（01100100 = 100 )，高位放前面(codew.. : or + macosx) : : powerpc上面运行结果是：0， : pc上面运行结果是1 : (以下引言省略...) ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日20:40:42 星期二) 提到： 我也纳闷是1 3 1 1不就有4bit的1了 【 在 wuxuemin 的大作中提到: 】 : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~大小端确实就是字节间的序 : ~~~~~~~~~~~~~~这个和MAC应该是相同的吧，但上面 CSgtree同学的MAC事实�.. : : ~~~~~~~~~~~~~~~~~这个大家都一致 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日20:45:30 星期二) 提到： 【 在 justicezyx 的大作中提到: 】 : 我琢磨了一下,这题跟大小端无关.而是在于字节内的比特位序. : 0------7 or 7------0 : -------- -------- : 00100110 01100100 : s1|s2|s3- -s3|s2|s1 : 结果都应该是s3=4.其实就是上面说的字节内位序和字节间序是一致的,否则会得出矛.. : 结果. 可是事实上 CSgtree说在PC上结果是1 mac结果也是1 ☆──────────────────────────────────────☆ aSB (Go) 于 2007年06月05日20:52:17 星期二) 提到： 基本是正确的，我看了一下ｖｃ２００５的实现 １.取两个字节放到ａｘ中（这一步说明结果与大小数端无关） ２.变量按先声明的放在低位的形式进行存放，即 0000000| 001| 100| 100 s3 s2 s1 3.与其说是平台相关，我更愿意相信是编译器相关（也许标准有规定，我没有查过） 【 在 Magiiii 的大作中提到: 】 : 其实这里的区别主要在于struct位段从低地址开始分配还是从高地址开始分配，而不.. : 小数端，我觉得大小数端应该是在字节序而不是比特序，当然这也是一个定义的问题。 : 而且这题和编译器非常相关 : 所以总结下来此题的结果和系统太相关了，标准答案基本是错的 : 顺便付我找到的CSDN的帖： : http://topic.csdn.net/t/20050904/12/4248520.html : pc上面是1，powerpc上面是0(vc6.0,windowsxp)， : pc上面是：100, 100, 001 ( 001100100 = 100 ) ,低位放在低�.. : : powerpc上面是：011，001，000（01100100 = 100 )，高位放前面(codew.. : or + macosx) : : powerpc上面运行结果是：0， : pc上面运行结果是1 : (以下引言省略...) ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日20:59:35 星期二) 提到： 上面这个就是程序跑出来的结果 【 在 wuxuemin 的大作中提到: 】 : 那大家可以以这个为根据来推了 : CSgtree你干脆把s1 s2 s3都输出来跟大家说一下 : （我没VC ）_-_! ☆──────────────────────────────────────☆ lingjie (owl) 于 2007年06月05日21:01:15 星期二 提到： 就编译来说，编译器也是平台的一部分。。。因素之一罢了。。 【 在 aSB (Go) 的大作中提到: 】 : 基本是正确的，我看了一下ｖｃ２００５的实现 : １.取两个字节放到ａｘ中（这一步说明结果与大小数端无关） : ２.变量按先声明的放在低位的形式进行存放，即 : 0000000| 001| 100| 100 : s3 s2 s1 : 3.与其说是平台相关，我更愿意相信是编译器相关（也许标准有规定，我没有查过） : .................（以下省略） ☆──────────────────────────────────────☆ aSB (Go) 于 2007年06月05日21:04:31 星期二) 提到： 恩，也可以这么说。 这个问题我觉得实现相关的可能性很大 【 在 lingjie 的大作中提到: 】 : 就编译来说，编译器也是平台的一部分。。。因素之一罢了。。 ☆──────────────────────────────────────☆ lingjie (owl) 于 2007年06月05日21:09:20 星期二 提到： 这个问题我不太喜欢发表看法，我想要做的是列一张表。编译器<保证选项相同>，机器 。统计下即可， 【 在 aSB (Go) 的大作中提到: 】 : 恩，也可以这么说。 : 这个问题我觉得实现相关的可能性很大 ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日21:15:23 星期二) 提到： 那好，等你结果好伐？（呵呵我这就一台破电脑） 几天后再给大家个总结 如果有人做过相关方面的实际工作 对这个问题应该很明白 【 在 lingjie 的大作中提到: 】 : 这个问题我不太喜欢发表看法，我想要做的是列一张表。编译器<保证选项相同>，机器 : 。统计下即可， ☆──────────────────────────────────────☆ lingjie (owl) 于 2007年06月05日21:18:21 星期二 提到： 不巧，我也只有一台机器，你应该找一个身在实验室的朋友，无非就是下面这些参数： 编译器和他的选项 有无操作系统和操作系统的种类 机器的cpu差别 【 在 wuxuemin (FanLisa) 的大作中提到: 】 : 那好，等你结果好伐？（呵呵我这就一台破电脑） : 几天后再给大家个总结 : 如果有人做过相关方面的实际工作 : 对这个问题应该很明白 ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月05日21:31:27 星期二) 提到： pc上是 4 4 1 mac上同学调了一下 v.c复制前内存里是8f e0 赋值后64 e0 因为隔壁的e0的关系 s3成1了 s1和s2分别是3和1 //以上都是调试的结果 【 在 wuxuemin 的大作中提到: 】 : 那大家可以以这个为根据来推了 : CSgtree你干脆把s1 s2 s3都输出来跟大家说一下 : （我没VC ）_-_! ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月05日21:50:25 星期二) 提到： 隔壁的应该也在赋值的时候被赋值了吧 当剩余的位空间不够位域变量时，在后续新的字节里存储这个位域变量 可能是刚好赋值的也是1？所以e0在赋值前后都没变化 【 在 CSgtree 的大作中提到: 】 : pc上是 4 4 1 : : mac上同学调了一下 : v.c复制前内存里是8f e0 : 赋值后64 e0 : 因为隔壁的e0的关系 : s3成1了 : s1和s2分别是3和1 : //以上都是调试的结果 ☆──────────────────────────────────────☆ Magiiii (Magi... (不会读的同学请查字典) 于 2007年06月05日23:02:32 星期二) 提到： 按CSDN上某人的说法，因为编译器（编译环境）不同，所以VC会清空后面多余的BYTE, De vC++不会。MAC应该也是这原因。 【 在 CSgtree 的大作中提到: 】 : pc上是 4 4 1 : : mac上同学调了一下 : v.c复制前内存里是8f e0 : 赋值后64 e0 : 因为隔壁的e0的关系 : s3成1了 : s1和s2分别是3和1 : //以上都是调试的结果 ☆──────────────────────────────────────☆ brase (做一个快乐的自由的高尚的人) 于 2007年06月05日23:27:29 星期二) 提到： 【 在 Magiiii 的大作中提到: 】 : 按CSDN上某人的说法，因为编译器（编译环境）不同，所以VC会清空后面多余的BYTE.. : vC++不会。MAC应该也是这原因。 ☆──────────────────────────────────────☆ mininova (小小新星) 于 2007年06月06日00:57:47 星期三 提到： linux2.6 gcc3.3.6 x86 跑出来的结果是 4 4 5 【 在 wuxuemin (FanLisa) 的大作中提到: 】 : #include <stdio.h> : void main() : { : union : { : struct : { : unsigned short s1:3; : unsigned short s2:3; : unsigned short s3:3; : .................（以下省略） ☆──────────────────────────────────────☆ ThinkLover (子矜) 于 2007年06月06日01:02:06 星期三) 提到： big endian 和little endian只是字节序。这个程序的输出与cpu，编译器都有关。 以现在最普遍的32位机器为例， unsigned short 为32位， 当足够分配s1,s2,s3时，大多 数编译器（VC, gcc等）分配一个单元（32 bit）. 大数端表示 0110 0100 | 0000 0000 s1 s2 s3依次为 100,100,001 －－－－－－－－－－－－ 小数端表示 0000 0000 | 0110 0100 s1 s2 s3依次从低位序取到高位序处 s1 s2 s3依次为 100,100,001 但并不表示输出一定是1 ， 与编译器对变量初始值有关。 比如vc 运行得1 gcc 运行得5。 【 在 wuxuemin 的大作中提到: 】 : #include <stdio.h> : void main() : { : union : { : struct : { : unsigned short s1:3; : unsigned short s2:3; : unsigned short s3:3; : }x; : char c; : }v; : v.c=100; : printf("%d\n",v.x.s3); : } : A:4 B:0 C:3 D:6 : 不是应该这样吗 ： : 如果位序是高位放低地址，低位放高地址 : （通常big endian字节序会有这样的位序） : (以下引言省略...) ☆──────────────────────────────────────☆ mininova (小小新星) 于 2007年06月06日01:04:50 星期三 提到： linux2.6 gcc3.2 gcc4 x86_64 结果都是4 4 1 上面的机器，跟-O结果也是4 4 1 了 【 在 mininova (小小新星) 的大作中提到: 】 : linux2.6 gcc3.3.6 x86 跑出来的结果是 4 4 5 : .................（以下省略） ☆──────────────────────────────────────☆ albor (射手座的馒头) 于 2007年06月06日01:42:29 星期三) 提到： vc6下跑的，s1,s2,s3分别4，4，1，但是有个问题，s3的最左边一位其实是没有赋值的， 应该是随着编译器或者随着系统的不同可能会有变化的，譬如在vc6+xp下，默认新开辟的 没有赋值的空间内每个字节的初始值为0xCC，假设在linux下跑出了5，那么说明linux默认 新开辟的没有赋值的空间初始值可能是0xFF（猜测的）。 本题觉得应该和字节的big/little endian无关， 比特序不影响结果的吧，如果大端比特序从左往右排放，char c这样赋值，但是s1,s2,s3 也会从左往右各占3bit，结果应该是不影响的。 可能更多需要考虑的是： 不同平台以及编译器下，struct声明的各个变量地址是否是依次递加的？ 【 在 mininova 的大作中提到: 】 : linux2.6 gcc3.2 gcc4 x86_64 结果都是4 4 1 : 上面的机器，跟-O结果也是4 4 1 了 ☆──────────────────────────────────────☆ ThinkLover (子矜) 于 2007年06月06日10:27:44 星期三 提到： 在gcc4.1.1下运行, 结果是4,4,5 但是并不是后一字节初始化为0xFF. 整个变量是0x4164 也就是赋值后,内存中为 0110 0100 | 0100 0001 至于为什么,要查gcc 的spec了 【 在 albor (射手座的馒头) 的大作中提到: 】 : vc6下跑的，s1,s2,s3分别4，4，1，但是有个问题，s3的最左边一位其实是没有赋值的， : 应该是随着编译器或者随着系统的不同可能会有变化的，譬如在vc6+xp下，默认新开辟的 : 没有赋值的空间内每个字节的初始值为0xCC，假设在linux下跑出了5，那么说明linux默认 : 新开辟的没有赋值的空间初始值可能是0xFF（猜测的）。 : 本题觉得应该和字节的big/little endian无关， : 比特序不影响结果的吧，如果大端比特序从左往右排放，char c这样赋值，但是s1,s2,s3 : 也会从左往右各占3bit，结果应该是不影响的。 : 可能更多需要考虑的是： : 不同平台以及编译器下，struct声明的各个变量地址是否是依次递加的？ : .................（以下省略） ☆──────────────────────────────────────☆ ThinkLover (子矜) 于 2007年06月06日11:21:57 星期三 提到： 发现gcc对变量未做初始化,也就是说,在gcc下,整个变量的后一字节是不确定的, 可以是0x4164, 当然也可以是0x5364等等,所以这个题的输出结果就不确定了, 可以是4, 4, 1; 也可以是4, 4, 5 【 在 albor (射手座的馒头) 的大作中提到: 】 : vc6下跑的，s1,s2,s3分别4，4，1，但是有个问题，s3的最左边一位其实是没有赋值的， : 应该是随着编译器或者随着系统的不同可能会有变化的，譬如在vc6+xp下，默认新开辟的 : 没有赋值的空间内每个字节的初始值为0xCC，假设在linux下跑出了5，那么说明linux默认 : 新开辟的没有赋值的空间初始值可能是0xFF（猜测的）。 : 本题觉得应该和字节的big/little endian无关， : 比特序不影响结果的吧，如果大端比特序从左往右排放，char c这样赋值，但是s1,s2,s3 : 也会从左往右各占3bit，结果应该是不影响的。 : 可能更多需要考虑的是： : 不同平台以及编译器下，struct声明的各个变量地址是否是依次递加的？ : .................（以下省略） ☆──────────────────────────────────────☆ CSgtree (w_ch) 于 2007年06月06日11:41:26 星期三 提到： 就这道题而言 因为char就一个字节 大小数叮(字节序)其实没有影响 但是若比特序与字节序一致的命题成立的话 不同比特序对输出肯定是有影响的 大数端 0110 0100 (从左到右比特序递增) s1从低比特序处开始取 分别会是011 001 00 小数端 0010 0110(从左到右比特序递增) s1还是从低比特序处取 分别是 001 001 10 因为是小数端比特序的机器表示 故实际是100 100 01 s3的取值确实与编译环境有关 s1 s2的取值在pc和mac都验证为一定的 【 在 albor (射手座的馒头) 的大作中提到: 】 : vc6下跑的，s1,s2,s3分别4，4，1，但是有个问题，s3的最左边一位其实是没有赋值的， : 应该是随着编译器或者随着系统的不同可能会有变化的，譬如在vc6+xp下，默认新开辟的 : 没有赋值的空间内每个字节的初始值为0xCC，假设在linux下跑出了5，那么说明linux默认 : 新开辟的没有赋值的空间初始值可能是0xFF（猜测的）。 : 本题觉得应该和字节的big/little endian无关， : 比特序不影响结果的吧，如果大端比特序从左往右排放，char c这样赋值，但是s1,s2,s3 : 也会从左往右各占3bit，结果应该是不影响的。 : 可能更多需要考虑的是： : 不同平台以及编译器下，struct声明的各个变量地址是否是依次递加的？ : .................（以下省略） ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月06日13:57:04 星期三) 提到： 前面Magiiii兄说位序是不变的，好像很肯定的样子 我也看到网上不少地方是这个意思： 比如“一个字节，读进硬件后，总归是“高比特在前”，至少硬件在逻辑上都是这样处理 所以至少在软件开发中，不存在所谓“比特顺序”的区别” 比如“在进行网络传输时，单字节的变量不用进行bit位的转换” 真是混乱啊~~~~~~~~!! 另外你说的“ 因为是小数端比特序的机器表示”是什么意思啊 我真是太猪了~~~ _-_! 你详细点解释一下好伐？ 【 在 CSgtree 的大作中提到: 】 : 就这道题而言 : 因为char就一个字节 : 大小数叮(字节序)其实没有影响 : 但是若比特序与字节序一致的命题成立的话 : 不同比特序对输出肯定是有影响的 : 大数端 : 0110 0100 (从左到右比特序递增) : s1从低比特序处开始取 : 分别会是011 001 00 : 小数端 : 0010 0110(从左到右比特序递增) : s1还是从低比特序处取 : 分别是 001 001 10 : 因为是小数端比特序的机器表示 : 故实际是100 100 01 : s3的取值确实与编译环境有关 : s1 s2的取值在pc和mac都验证为一定的 : (以下引言省略...) ☆──────────────────────────────────────☆ wuxuemin (FanLisa) 于 2007年06月06日14:56:29 星期三) 提到： 查了某编译器的资料 发现位域是先从高位（MSB)还是低位（LSB）开始是由编译器选项决定的。 比如 stucct field{ unsigned char a:1; unsigned char b:2; unsigned char c:3; unsigned char d:1; unsigned char e:3; unsigned char f:2; } 位域的分配根据编译器选项有两种方式 1种是a分配到MSB（超过本字节的位域在下个字节的MSB开始） 另一种是a分配到LSB（超过本字节的位域在下个字节的MSB开始） 如图（第一次传图，不知道会不会有问题） 根据题目 v.c=100; 则内存里数据为 MSB LSB ADD: 0110 0100 ADD+1: xxxx xxxx (x表示未知） 对应的S1 S2 S3根据编译器选项，分别有两种可能： 1）011 001 xxx 2) 100 100 xxx MS可以暂时结贴了 现在问题是 这些xxx怎么确定它们的值？？因为v.c=100; 并没有对其赋值啊 |
[转寄/推荐][转贴][删除][修改][设置可RE属性][上一篇][返回讨论区][下一篇][回文章][同主题列表][同主题阅读][从这里展开]