为什么按位取反运算符“〜”强制转换为int？ （从“ int”转换为“ unsigned char”可能会改变其值）

Question

GCC 4.9.1报告“警告：从'int'转换为'unsigned char'可能会更改其值[-Wconversion]”，其代码如下

#include <cstdlib>

int main( int , char*[] ) {
  unsigned char *dest = new unsigned char[16];
  const unsigned char *src = new unsigned char[16];
  for( size_t i = 0; i != 16; ++i) {
    dest[i] = ~(src[i]);
  }
  return 0;
}

显然， src和dest都是指向unsigned char数组的指针，我只希望后者成为前者的按位取反。 由于某些奇怪的原因， ~运算符似乎返回一个int ，从而触发警告。 为什么？ 这是预期的行为吗？

当然，我知道我可以使用static_cast<unsigned char>()来阻止警告，但是我觉得还有其他问题，并且警告不应该放在第一位。

Answer 1

我猜字面上的答案是因为标准这么说。 来自[expr.unary.op]：

~的操作数应具有整数或无范围的枚举类型； 结果是一个操作数的补码。 进行整体促销。 结果的类型是提升操作数的类型。

根据[conv.prom]，它是：

如果int可以表示源类型的所有值，则整数转换等级（4.13）小于int等级的bool类型， bool ， char16_t ， char32_t或wchar_t的整数类型的prvalue可以转换为int类型的prvalue。 ; 否则，可以将源prvalue转换为unsigned int类型的prvalue。

并且int等级高于unsigned char 。 因此，是的，这是预期的行为，并且显式static_cast抑制了警告。

Answer 2

表达式中的所有操作数至少都提升为int ，因为int应该表示给定体系结构的“自然”整数类型。

因此，此警告是正确的-赋值右侧的类型将为int （对于某些人来说，它可能指示优化的位置*）， static_cast是一个很好的解决方案（我将向其添加0xFF掩码，只是为了确保正确地声明状态）我的意图）。

*）例如：一个可以一次取反4个字节，从而更好地利用CPU。 一些编译器可能会自己完成。