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

Question

我已经阅读了关于C ++中const-correctness的所有建议，并且它（部分）很重要，因为它有助于编译器优化代码。 我从未见过的是关于编译器如何使用这些信息来优化代码的一个很好的解释，甚至连好书都没有解释幕后发生的事情。

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

Answer 1

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

Herw Sutter在GotW＃81文章中解释了为什么编译器在通过const引用传递参数时或者在声明const返回值时无法优化任何内容。 原因是编译器无法确定引用的对象是否会被更改，即使声明为const：一个可以使用const_cast，或者某些其他代码可以在同一个对象上具有非const引用。

然而，引用Herb Sutter的文章：

只有一种情况说“const”可以真正意味着某种东西，那就是当对象在它们被定义的点被制成const时。 在这种情况下，编译器通常可以成功地将这种“真正的const”对象放入只读存储器中[...]。

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

Answer 2

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

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

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

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

请注意，只有当实际对象是const时，这个东西才适用 - 它不适用于通过const指针或引用访问的对象，因为这些访问路径可能导致非const的对象（它甚至可以很好地定义为通过const更改对象）指针/引用，只要实际对象是非const并且您丢弃了对象的访问路径的常量）。

在实践中，我认为没有编译器可以对各种const对象执行任何重要的优化。 但对于原始类型的对象（整数，字符等），我认为编译器可以非常积极地优化这些项的使用。

Answer 3

handwaving开始

本质上，数据修复得越早，编译器就可以越多地绕数据的实际分配移动，确保管道不会停顿

结束了

Answer 4

咩。 正确性更像是一种样式/错误检查，而不是优化。 完全优化的编译器将遵循变量使用，并且可以检测变量何时是否有效。

除此之外，编译器不能依赖于你说实话 - 你可能会丢弃它不知道的库函数中的const。

所以，是的，const-correctness是一个值得瞄准的东西，但它并没有告诉编译器任何它不会为自己弄清楚，假设一个好的优化编译器。

Answer 5

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

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

void someType::somefunc();

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

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

Answer 6

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

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

Answer 7

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

编译器优化只有一种代码，即代码中的代码

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

如果其他99％的代码被优化到N度，它就不会产生差异，因为它只在程序计数器实际花费时间的代码中很重要（可以通过采样找到）。

Answer 8

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

Answer 9

const-correctness也可用作文档。 如果函数或参数被列为const，我不需要担心从我的代码下面更改的值（除非团队中的其他人非常顽皮）。 不过，如果它没有内置到库中，我不确定它是否真的值得。

Answer 10

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

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

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

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

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

Answer 11

这段代码，

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 12

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