C++十六进制表示法和位运算符的性能

Question

也许是一个愚蠢的问题，但我有一个C++应用程序，我经常这样做：

x & 0xff

其中x是32位整数。在进行AND操作时，将前导零也考虑在内是否会有性能优势？

x & 0x000000ff

我读到任何小于int类型的操作数在运算之前都会被提升为int类型。我猜这是编译器自动执行的优化，或者我在这里加前导零有助于MSVC做些什么吗？

- Jeroen Baert

---

我非常确定任何编译器都会对其进行优化，但您始终可以检查生成的汇编代码以自行了解情况。 - mcserep

即使编译器将一个字节移动到寄存器中，CPU也会进行零扩展。编译器不应该费心保留前导零。 - owacoder

0x000000ff和0xff都是int字面量，因此在类型和性能上没有区别。0x000000ff可能会对编译器的性能产生几纳秒的影响或类似的影响。 - phuclv

Answer 1

在您的源代码中添加这些零没有任何影响。它们将在词法分析阶段被移除，甚至在编译器完成解析代码之前就会被移除。它们不会影响代码生成。

- melpomene

Answer 2

编写以下代码：

#include <iostream>

int main()
{
    int x = 400;
#ifdef SHORT
    std::cout << (x & 0xFF) << std::endl;
#else
    std::cout << (x & 0x000000FF) << std::endl;
#endif
    return 0;
}

使用-DSHORT编译和不使用编译：

g++ -std=c++11 -DSHORT main.cpp -o test_short

g++ -std=c++11 main.cpp -o test_long

比较生成的可执行文件，它们完全相同（使用-O3选项测试过与未测试过均是如此）。因此，g++编译器正确处理了这个问题，在编写代码时不需要考虑这一点（添加零对生成的代码没有任何影响）。我没有MSVC，但您可以进行完全相同的测试并检查输出是否不同！

- jpo38

---

注意：OP没有使用g++。 - owacoder

@owacoder：没错，我漏了这个：他可以用任何编译器重复相同的测试....;-) - jpo38

这就像检查73 * 137今天是否仍然等于昨天的10001一样 - 任何怀疑都是适得其反的。 - anatolyg

@anatolyg：我不明白你的评论。拥有相同的可执行文件肯定意味着在代码中添加零是完全没有意义的，不是吗？ - jpo38