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

【问题标题】：Why does bit-wise negate operator "~" cast to int? (conversion to ‘unsigned char’ from ‘int’ may alter its value)为什么按位取反运算符“〜”强制转换为int？（从“int”转换为“unsigned char”可能会改变其值）
【发布时间】：2015-11-23 03:54:13
【问题描述】：

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>() 来阻止警告，但我觉得还有其他问题，并且警告不应该放在首位。

【问题讨论】：

标签： c++ type-conversion bit-manipulation compiler-warnings

【解决方案1】：

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

~ 的操作数应为整数或无范围枚举类型；结果是其操作数的反码。进行整体促销。 结果的类型是提升的操作数的类型。

根据 [conv.prom] 是：

除bool、char16_t、char32_t 或wchar_t 之外的整数类型的纯右值，其整数转换 rank (4.13) 小于int 的rank 可以转换为int 类型的prvalue 如果int 可以代表所有源类型的值；否则，可以将源纯右值转换为unsigned int 类型的纯右值。

并且int 的排名高于unsigned char。所以是的，这是预期的行为，明确的static_cast 会压制警告。

【讨论】：

【解决方案2】：

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

所以这个警告是正确的 - 赋值右侧的类型将是 int（对于某些人来说，它可能表示优化位置*），static_cast 是一个很好的解决方案（我会为 0xFF 添加掩码到它，只是为了确定并正确说明我的意图）。

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

【讨论】：