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的差异的确够隐晦的。

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

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/145302.html原文链接：https://javaforall.cn