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 ++编译器的每个平台上使用的二进制补码表示。

符号扩展意味着目标变量上符号位的所有内容都将填充符号位，从而产生结果中的所有f个。正如您所指出的，您可以将0x7f移位3个字节而不会发生这种情况，这是因为0x7f=0b01111111。在转换之后，得到0x7f000000这是最大的signed int，即不影响符号位的最大数字。因此，在转换中，0已延长。

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

uint64_t temp = uint64_t(0xff) << 24

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

4 个答案: