C++ 中的常量和编译器优化

Question

我已经阅读了 C++ 中关于 const 正确性的所有建议，并且它很重要（部分），因为它可以帮助编译器优化代码。 我从未见过关于编译器如何使用这些信息来优化代码的很好的解释，即使是好书也没有继续解释幕后发生的事情。

例如，编译器如何优化声明为 const 的方法与不是但应该声明为 const 的方法。 当引入可变变量时会发生什么？ 它们会影响 const 方法的这些优化吗？

Answer 1

const 是直接优化的最明显的一点是向函数传递参数。 确保函数不会修改数据通常很重要，因此函数签名的唯一真正选择是：

void f(Type dont_modify); // or
void f(Type const& dont_modify);

当然，这里真正的魔力是传递引用而不是创建对象的（昂贵的）副本。 但如果引用没有标记为 const，这会削弱该函数的语义并产生负面影响（例如使错误跟踪变得更加困难）。 因此，const 在这里启用了优化。

/编辑：实际上，一个好的编译器可以分析函数的控制流，确定它不会修改参数并本身进行优化（传递引用而不是副本）。 这里的const只是对编译器的帮助。 然而，由于 C++ 有一些相当复杂的语义，并且这种控制流分析对于大型函数来说可能非常昂贵，因此我们可能不应该依赖编译器来实现这一点。 有人有任何数据支持我/证明我错了吗？

/EDIT2：是的，一旦自定义复制构造函数发挥作用，它就会变得更加棘手，因为不幸的是，不允许编译器在这种情况下省略调用它们。

Answer 2

此代码

class Test
{
public:
  Test (int value) : m_value (value)
  {
  }

  void SetValue (int value) const
  {
    const_cast <Test&>(*this).MySetValue (value);
  }

  int Value () const
  {
    return m_value;
  }

private:
  void MySetValue (int value)
  {
    m_value = value;
  }

  int
    m_value;
};

void modify (const Test &test, int value) 
{
  test.SetValue (value);
}

void main ()
{
  const Test
    test (100);

  cout << test.Value () << endl;
  modify (test, 50);
  cout << test.Value () << endl;
}

输出：

100
50

这意味着 const 声明的对象已在 const 成员函数中更改。 C++ 语言中 const_cast（以及 mutable 关键字）的存在意味着 const 关键字无法帮助编译器生成优化的代码。 正如我在之前的文章中指出的，它甚至可以产生意想不到的结果。

作为基本规则：

const !=优化

事实上，这是一个合法的 C++ 修饰符：

volatile const

Answer 3

const 帮助编译器优化主要是因为它使您可以编写可优化的代码。 除非你输入const_cast。

Answer 4

我认为const关键字主要是为了程序语义的编译检查而引入的，而不是为了优化。

Herb Sutter 在 GotW #81 文章 中很好地解释了为什么编译器不能通过 const 引用传递参数或声明 const 返回值时优化任何内容。 原因是编译器无法确保引用的对象不会更改，即使声明为 const ：可以使用 const_cast，或者某些其他代码可以在同一对象上拥有非常量引用。

然而，引用 Herb Sutter 的文章：

[只有]一种情况说
“const”确实可以意味着一些东西，并且
那就是当对象被设为常量时
它们被定义的点。 在那里面
在这种情况下，编译器通常可以
成功地把这样的“真正的常量”
对象写入只读内存[...]。

本文还有很多内容，因此我鼓励您阅读它：之后您将对持续优化有更好的理解。

Answer 5

让我们忽略方法，只看 const 对象； 编译器在这里有更多的优化机会。 如果一个对象被声明为 const，则 (ISO/IEC 14882:2003 7.1.5.1(4))：

除了声明的任何类成员
可变（7.1.1）可以修改，任何
尝试修改 const 对象
在其生命周期内（3.8）导致
未定义的行为。

让我们忽略可能具有可变成员的对象 - 编译器可以自由地假设该对象不会被修改，因此它可以产生显着的优化。 这些优化可以包括以下内容：

• 将对象的值直接合并到机器指令操作码中
• 完全消除永远无法到达的代码，因为 const 对象用于编译时已知的条件表达式
• 如果 const 对象正在控制，则展开循环循环的迭代次数

请注意，此内容仅适用于实际对象为 const 的情况 - 它不适用于通过 const 指针或引用访问的对象，因为这些访问路径可能会导致非 const 对象（甚至更好） - 定义为通过 const 指针/引用更改对象，只要实际对象是非常量，并且您放弃了对象访问路径的常量性）。

实际上，我认为没有编译器可以对所有类型的 const 对象执行任何重要的优化。 但对于原始类型（整数、字符等）的对象，我认为编译器在优化方面可能非常积极
这些物品的使用。

Answer 6

handwaving 开始

从本质上讲，数据越早被修复，编译器就越能在数据的实际分配中移动，确保管道不会停止

end handwaving

Answer 7

嗯。 常量正确性更多的是一种样式/错误检查而不是优化。 全面优化的编译器将跟踪变量的使用情况，并可以检测变量何时是有效的 const。

除此之外，编译器不能依赖你告诉它真相——你可能会丢弃它不知道的库函数中的 const 。

所以，是的，常量正确性是一个值得追求的目标，但它不会告诉编译器任何它自己无法弄清楚的事情，假设有一个良好的优化编译器。

Answer 8

它不会优化声明为 const 的函数。

它可以优化调用声明为const的函数的函数。

void someType::somefunc();

void MyFunc()
{
    someType A(4);   // 
    Fling(A.m_val);
    A.someFunc();
    Flong(A.m_val);
}

这里要调用 Fling，值 A.m_val 必须加载到 CPU 寄存器中。 如果 someFunc() 不是 const，则必须在调用 Flong() 之前重新加载该值。 如果 someFunc 是 const，那么我们可以使用仍在寄存器中的值调用 Flong。

Answer 9

将方法设置为const的主要原因是为了const的正确性，而不是为了方法本身可能的编译优化。

如果变量是const，那么它们（理论上）可以被优化掉。 但编译器只能看到范围。 毕竟编译器必须允许在其他地方使用 const_cast 修改它们。

Answer 10

这些都是正确的答案，但答案和问题似乎假定了一件事：编译器优化实际上很重要。

只有一种代码对编译器优化很重要，即在

• 紧密内部循环的代码中，
• 在您编译的代码中，而不是第 3 方库，
• 不包含函数或方法调用（甚至是隐藏的调用），
• 程序计数器花费了相当大一部分时间的地方

如果其他 99% 的代码被优化到 N 级，那不会有什么不同，因为它只在程序计数器实际花费时间的代码中重要（您可以通过抽样找到）。

Answer 11

如果优化器实际上将大量库存放入 const 声明中，我会感到惊讶。 有很多代码最终会抛弃常量性，这将是一个非常鲁莽的优化器，它依赖于程序员声明来假设状态何时可能改变。

Answer 12

const-正确性作为文档也很有用。 如果函数或参数被列为 const，我不需要担心代码中的值发生变化（除非团队中的其他人非常顽皮）。 不过，如果它没有内置到库中，我不确定它是否真的值得。