php 0xffffffff,0xffffffff - 依睛(IT blog) 我回来了,PHPC/C++ LINUX - IT博客

今早ssjjll问我一个位操作的问题,原本以为非常easy的,可是程式的输出总是不尽人意。开始认为是编译器的错误,后来看文件才知道是自己学业不精,乃功力不足所致。失望!对C我一直认为全掌控了,而C++也练到了7、8重的境界,不料今日还是阴沟翻船。记下来,勿忘瓜耻!

先看出现问题的代码:int a = 32;

int x = 0xFFFFFFFF;

cout << int(0xFFFFFFFF >> 32) << endl;

cout << int(x >> 32) << endl;

cout << int(0xFFFFFFFF >> a) << endl;

输出:VC7.1 Debug 为 0,  -1,  -1.   Release为 0, 0, 0.疑点:sizeof(int)==4。所以左移32位后,我认为int变量应该被清0了。但输出结果却不一致,更奇怪的是debug/release的输出也不相同。我当时猜测是int应该改为unsigned int的问题,(后来发现直觉有一定道理,但不是问题关键)。把程式改为全用unsignedint,输出不变!也就是:

unsigned 0xFFFFFFFF 右移32次,居然还得到0xFFFFFFFF!更加想不通了。

解答:

仔细看了一下C/C++ Standard和MSDN,原来是我对位移操作的理解不够完备所致。

1. 所有的位移操作的右操作数必须小于左操作数的位长度,否则结果未定义。

2. 右移操作对于unsigned系列,高位一直补0。对于signed系列,高位补符号位。

3. 在操作过程当中,有可能产生Integral Promotions。这就比较复杂了。C++中采用和C相同的策略,提升后的的量总是“保值的”,即原有的bit值不变;但不一定是“保号的”。运算中,如果char/bit field不能保持全部的值,就会被提升到int型,如果int也不能保存全部的值就会被提升至unsigned。有几种罕见的情况,保值和保号的运算会导致不同的值:

(1) /, %, /=, %=, , >=运算依赖于符号,应用时可能导致不同结果。(2)>>, >>= 运算有时依赖于符号位。(3)函数重载参数可能依赖于符号。

由此可见,上述程式的位操作次数大于等于了整数的位数,输出结果不确定也是正常的。为了完全理解这个问题,再作下面的试验:int a = 31;

int x = 0xFFFFFFFF;

cout << typeid(0xFFFFFFFF).name() << endl;

cout << typeid(0x0FFFFFFF).name() << endl;

cout << int(0xFFFFFFFF >> 31) << endl;

cout << int(x >> 31) << endl;

cout << int(0xFFFFFFFF >> a) << endl;

输出:Debug/Release下均为 unsigned int, int, 1, -1, 1

这里能清晰地看到0xFFFFFFFF之内被unsigned int放下,所以其类型是unsigned int;而0x0FFFFFFF一个int就能放下了,所以类型是int。两个1的输出没什么好说的。-1的输出是因为x为有符号数,且符号位是1,所以高位补1,结果总不变。但这个1和-1的差异的确够隐晦的。

总结经验:当对变量进行位移操作时,逻辑上应该尽可能使用无符号数。位移长度应严格控制在字长以内。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值