为什么 C 中的右移位运算符 (`>>`) 在移位 32 位时会产生意外结果？

C 中的

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

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

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

<code class="cpp">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) <p>令人惊讶的是。 ，该程序的输出显示了意想不到的结果：</p>
<pre class="brush:php;toolbar:false">foo(1, 32): 1 // Should be 0
bar(1, 32): 0
1 >> 32: 0
(int)1 >> (int)32: 0

这些结果背后的基本原理在于 CPU 和编译器的内部工作原理。

foo() 的行为函数

在foo()函数中，移位操作是在没有强制转换的情况下执行的，导致CPU执行逻辑右移，在许多架构上，逻辑右移被实现为>。 > (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 特定行为

右移的实现不同 CPU 的操作可能有所不同。在 x86/x86-64 架构上，逻辑右移实际上是 >> (b % 32 或 64)，取决于模式。然而，在 ARM 处理器上，右移运算保证大于或等于 32 的移位为零。

结论

使用右移运算符时，这一点至关重要考虑潜在的未定义行为，特别是当移位计数超过操作数的长度时。转换为更广泛的整数类型（例如 64 位整数）可以确保不同 CPU 和编译器之间的结果一致。

以上是为什么 C 中的右移位运算符 (`>>`) 在移位 32 位时会产生意外结果？的详细内容。更多信息请关注PHP中文网其他相关文章！