C 中的

>`) 在移位 32 位时会产生意外结果？ " />

右移运算符的意外行为 (1 >> 32)

在编程领域，通常使用右移运算符 (>>)执行按位运算，特别是将整数除以 2 的幂。但是，当移位较大的值时，可能会出现奇怪的行为，如以下 C 代码所示：

int foo(int a, int b) {
   return a >> b;
}

int bar(uint64_t a, int b) {
   return a >> b;
}

int main() {
    std::cout > 32: " > 32) > (int)32: " > (int)32) 
令人惊讶的是，这个程序的输出显示出意想不到的结果：
foo(1, 32): 1 // Should be 0
bar(1, 32): 0
1 >> 32: 0
(int)1 >> (int)32: 0
这些结果背后的基本原理在于 CPU 和编译器的内部工作原理。
foo() 函数的行为
在foo()函数中，移位操作是在没有强制转换的情况下执行的，导致CPU执行逻辑右移。在许多架构上，逻辑右移被实现为 a >> (b % 32)，有效地忽略 b 的高位。因此，foo(1, 32) 结果为 1 >> (32 % 32)，其计算结果为 1 >> 0，产生 1。
为什么转换为 64 位整数很重要？
在bar()函数中，提供了一个64位无符号整数，确保结果保证为0，因为b(32)小于操作数中的位数(64 ）。然而，当 b 更改为 64 时，结果变得不可预测，并且可能仍会产生 1。
编译器优化
在 1 >> 32 且 (int )1 >> (int)32，编译器在编译时优化这些常量表达式。该标准指定了右移的未定义行为，其中计数为负数或大于或等于操作数的长度。由于 32 超出了操作数的长度，编译器无法确定结果并输出 0 作为安全后备。
CPU-Specific Behavior
右移的实现不同 CPU 的操作可能有所不同。在 x86/x86-64 架构上，逻辑右移实际上是 a >> (b % 32 或 64)，具体取决于模式。然而，在 ARM 处理器上，右移运算保证大于或等于 32 的移位为零。
结论
使用右移运算符时，这一点至关重要考虑潜在的未定义行为，特别是当移位计数超过操作数的长度时。转换为更广泛的整数类型（例如 64 位整数）可以确保不同 CPU 和编译器之间的结果一致。