Question

我无法弄清楚为什么包容性OR会返回错误的结果。

char arr[] = { 0x0a, 0xc0 };
uint16_t n{};

n = arr[0]; // I get 0x000a here.
n = n << 8; // Shift to the left and get 0x0a00 here.
n = n | arr[1]; // But now the n value is 0xffc0 instead of 0x0ac0.

这个例子中的错误是什么？控制台应用程序，2017年MVS社区。

Answer 1

非预期的0xff是由0xc0 sign bit extension引起的。

0xc0 = 0b11000000

因此，设置最上面的位表示char的符号（signed char）。

请注意，C ++中的所有算术运算和按位运算至少使用int（或unsigned int）。较小的类型在之前被提升并在之后被剪裁。

请注意char可能已签名或未签名。这依赖于编译器实现。显然，它是在OP的情况下签署的。为防止意外的符号扩展，参数必须变为无符号（足够早）。

演示：

#include <iostream>

int main()
{
  char arr[] = { '\x0a', '\xc0' };
  uint16_t n{};

  n = arr[0]; // I get 0x000a here.
  n = n << 8; // Shift to the left and get 0x0a00 here.
  n = n | arr[1]; // But now the n value is 0xffc0 instead of 0x0ac0.
  std::cout << std::hex << "n (wrong): " << n << std::endl;
  n = arr[0]; // I get 0x000a here.
  n = n << 8; // Shift to the left and get 0x0a00 here.
  n = n | (unsigned char)arr[1]; // (unsigned char) prevents sign extension
  std::cout << std::hex << "n (right): " << n << std::endl;
  return 0;

}

会话：

g++ -std=c++11 -O2 -Wall -pthread main.cpp && ./a.out
n (wrong): ffc0
n (right): ac0

coliru上的生活演示

注意：

我不得不将char arr[] = { 0x0a, 0xc0 };
更改为char arr[] = { '\x0a', '\xc0' }; to以接受严重的编译器投诉。我想，这些投诉与这个问题密切相关。

Answer 2

您已成为签名整数提升的受害者。

将0xc0分配给数组中的第二个元素（由于MVS而签名的char默认值）时，表示如下：

arr[1] = 1100 - 0000, or in decimal -64

当它转换为uint16_t时，会将其提升为值为-64的整数。这是：

n = 1111 - 1111 - 1100 - 0000 = -64

由于整数的2's complement实现。

因此：

n          = 1111 - 1111 - 1100 - 0000 
arr[1]     = 0000 - 0000 - 1010 - 0000 (after being promoted)

n | arr[1] = 1111 - 1111 -1110-0000 = 0xffc0

Answer 3

我通过以下方式让它正常工作：

int arr[] = { 0x0a, 0xc0 };
int n{};

n = arr[0]; // I get 0x000a here.
n = n << 8; // Shift to the left and get 0x0a00 here.
n = n | arr[1];
std::cout << n << std::endl;

如果你离开'arr＆＃39;那么会有一些截断。数组为char。

使用按位包含OR的错误结果

3 个答案: