为什么将 0xff 左移 24 位会导致值不正确？

Question

我想将 0xff 左移 3 个字节并将其存储在 uint64_t 中，它应该可以这样工作：

uint64_t temp = 0xff << 24;

这会产生0xffffffffff000000 的值，这绝对不是预期的0xff000000。

但是，如果我将其移动少于 3 个字节，则会得到正确答案。

此外，尝试将 0x01 左移 3 个字节确实有效。

这是我的输出：

0xff shifted by 0 bytes: 0xff
0x01 shifted by 0 bytes: 0x1
0xff shifted by 1 bytes: 0xff00
0x01 shifted by 1 bytes: 0x100
0xff shifted by 2 bytes: 0xff0000
0x01 shifted by 2 bytes: 0x10000
0xff shifted by 3 bytes: 0xffffffffff000000
0x01 shifted by 3 bytes: 0x1000000

通过一些实验，每个 uint64_t 左移最多 3 位，直到 0x7f，产生 0x7f000000。 0x80 产生 0xffffffff80000000。

有人对这种奇怪的行为有解释吗？ 0xff000000 肯定落在 uint64_t 的 2⁶⁴ - 1 限制内。

Answer 1

有人对这种奇怪的行为有解释吗？

是的，操作类型始终取决于操作数类型，而从不取决于结果类型：

double r = 1.0 / 2.0; 
    // double divided by double and result double assigned to r
    // r == 0.5

double r = 1.0 / 2; 
    // 2 converted to double, double divided by double and result double assigned to r
    // r == 0.5

double r = 1 / 2; 
    // int divided by int, result int converted to double and assigned to r
    // r == 0.0

当你理解并记住这一点时，你就不会再犯这个错误了。

Answer 2

我怀疑这种行为取决于编译器，但我看到了同样的事情。

修复很简单。请务必在执行移位之前将 0xff 转换为 uint64_t 类型。这样编译器就会把它当作正确的类型来处理。

uint64_t temp = uint64_t(0xff) << 24

Answer 3

左移会创建一个负数（32 位），然后填充为 64 位。

试试

0xff << 24LL;

Answer 4

让我们将您的问题分成两部分。第一个是移位操作，另一个是转换为uint64_t。

就左移而言，您在 32 位（或更小）架构上调用了未定义的行为。正如其他人所提到的，操作数是int。具有给定值的 32 位 int 将是 0x000000ff。请注意，这是一个有符号数，因此最左边的位是符号。根据标准，如果移位影响符号位，则结果未定义。这取决于实现的心血来潮，它随时可能发生变化，如果编译器在编译时识别它，它甚至可以被完全优化掉。后者是不现实的，但实际上是允许的。虽然您永远不应该依赖这种形式的代码，但这实际上并不是让您感到困惑的行为的根源。

现在，第二部分。左移操作的未定义结果必须转换为uint64_t。有符号到无符号整数转换的标准状态：

如果目标类型是无符号的，则结果值是等于源值模 2n 的最小无符号值，其中 n 是用于表示目标类型的位数。

也就是说，根据目标类型是更宽还是更窄，有符号整数被符号扩展[脚注 1] 或截断，无符号整数分别被零扩展或截断。

脚注阐明符号扩展仅适用于二进制补码表示，目前每个平台都使用 C++ 编译器。

符号扩展意味着目标变量上符号位剩下的所有内容都将被符号位填充，这会在结果中产生所有fs。正如您所指出的，您可以将0x7f 左移 3 个字节而不会发生这种情况，这是因为0x7f=0b01111111。移位后，你得到0x7f000000，它是最大的有符号整数，即不影响符号位的最大数。因此，在转换中，扩展了一个0。

将左操作数转换为足够大的类型可以解决这个问题。

uint64_t temp = uint64_t(0xff) << 24