C ++ - 逐位不UCHAR产生INT [英] C++ - Bit-wise not of uchar produces int

问题描述

我对C ++的行为将逐位不是时候unsigned char类型感到惊讶。

I am surprised by C++'s behavior when applying bit-wise not to an unsigned char.

以二进制值 01010101B ，这是将0x55 或 85 。运用逐位不是八位重新presentation应该产生 10101010b ，这是和0xAA 或 170 。

Take the binary value 01010101b, which is 0x55, or 85. Applying bit-wise not on an eight bit representation should yield 10101010b, which is 0xAA, or 170.

不过，我不能重现C ++以上。下面这个简单的断言失败。

However, I cannot reproduce the above in C++. The following simple assertion fails.

assert(static_cast<unsigned char>(0xAAu) == ~static_cast<unsigned char>(0x55u));

我打印将0x55 ，和0xAA 的值，〜将0x55 （如UCHAR）具有以下code。它揭示了逐位不是没有做什么，我希望它做的事。

I printed the values of 0x55, 0xAA, and ~0x55 (as uchar) with the following code. And it reveals that the bit-wise not does not do what I expect it to do.

std::cout << "--> 0x55: " << 0x55u << ", 0xAA: " << 0xAAu << ", ~0x55: "
     << static_cast<unsigned>(~static_cast<unsigned char>(0x55u)) << std::endl;

--> 0x55: 85, 0xAA: 170, ~0x55: 4294967210

这就是印将0x55〜的数量等于 11111111111111111111111110101010b ，这是32位比特明智的，不要的将0x55 。因此，〜运算符的32位整数操作，即使我明确地转换输入到 unsigned char型。这是为什么？

The number that is printed for ~0x55 is equal to 11111111111111111111111110101010b, which is the 32-bit bit-wise not of 0x55. So, the ~ operator is operating on 32-bit integers even if I explicitly cast the input to an unsigned char. Why is that?

我申请另外一个测试，看看有什么键入〜运营商的收益。它原来是 INT 上的 unsigned char型输入：

I applied another test to see what type the ~ operator returns. And it turns out to be int on an unsigned char input:

template <class T>
struct Print;

// inside main()    
Print<decltype(~static_cast<unsigned char>(0x55))> dummy;

产生以下编译器错误，这表明，该结果是一个类型的 INT 。

error: implicit instantiation of undefined template 'Print<int>'
    Print<decltype(~static_cast<unsigned char>(0x55u))> dummy;

我是什么做错了吗？或者说，我怎么C ++产生和0xAA 从将0x55〜？

的全code是这里 的

推荐答案

积分促销活动都在〜的操作数来完成，我们可以通过进入的草案的C ++标准部分 5.3.1 的一元运算符的它说（的重点煤矿的）：

Integral promotions are performed on the operand of ~ we can see this by going to the draft C++ standard section 5.3.1 Unary operators which says (emphasis mine):

〜的操作应具有完整的或无作用域的枚举类型;该
  结果就是它的操作数的补数。 积分促销
  执行的结果的类型是提升操作数的类型[...]

The operand of ˜ shall have integral or unscoped enumeration type; the result is the one’s complement of its operand. Integral promotions are performed. The type of the result is the type of the promoted operand [...]

和积分促销活动将在第 4.5 的积分促销活动的说：

and the integral promotions are covered in section 4.5 Integral promotions and say:

整数类型比布尔，char16_t，char32_t，或以外的prvalue
  为wchar_t其整转换排名（4.13）小于军衔
  INT可以被转换成int类型的prvalue如果INT都可以重新present
  源类型的值;

A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type;

有关完整性，看到的 unsigned char型的排名低于军衔的 INT 的大家可以去节 4.13 的整数转换等级的它说：

For completeness, to see that unsigned char rank is less than the rank of int we can go to section 4.13 Integer conversion rank which says:

有符号整数类型的秩应大于军衔更大
  任何符号整型具有更小的尺寸。

The rank of a signed integer type shall be greater than the rank of any signed integer type with a smaller size.

和

字符的级别应等于符号字符和无符号的秩
  字符。

The rank of char shall equal the rank of signed char and unsigned char.

一个解决办法是将结果分配到的 unsigned char型的当中，这是安全的，因为你不必担心有符号整数溢出。

One solution would be to assign the result to an unsigned char which, this is safe since you don't have to worry about signed integer overflow.

由于本福格特指出，这将符合有一个系统，其中的sizeof（int）的== 1 和 CHAR_BIT＆GT; = 32 。在这种情况下，unsigned char型的秩woudl不低于INT，因此推广将是无符号整型。我们不知道，这其实发生在任何系统中。

As Ben Voigt points out it would compliant to have a system where sizeof (int) == 1 and CHAR_BIT >= 32. In which case the rank of unsigned char woudl not be less than int and therefore the promotion would be to unsigned int. We do not know of any systems that this actually occurs on.

这篇关于C ++ - 逐位不UCHAR产生INT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！