优化掉“while(1);”在 C++0x 中

Question

已更新，见下文！

我听说并读到 C++0x 允许编译器为以下代码片段打印“Hello”，

#include <iostream>

int main() {
  while(1) 
    ;
  std::cout << "Hello" << std::endl;
}

这显然与线程和优化功能有关。在我看来，这可能会让很多人感到惊讶。

有人对为什么有必要允许这样做有一个很好的解释吗？作为参考，最新的 C++0x 草案位于 6.5/5

在 for 语句的情况下，在 for-init-statement 之外的循环，

• 不调用库 I/O 函数，并且
• 不访问或修改易失性对象，并且
• 不执行同步操作 (1.10) 或原子操作（第 29 条）

可以假定实现终止。 [注意：这是为了允许编译器转换 即使无法证明终止，也可以删除空循环。 ——尾注]

编辑：

这篇富有洞察力的文章介绍了该标准文本

不幸的是，没有使用“未定义行为”这个词。然而，只要标准说“编译器可以假设 P”，就意味着具有 not-P 属性的程序具有未定义的语义。

这是正确的吗？编译器是否允许为上述程序打印“Bye”？

---

此处有一个更具洞察力的帖子，这是关于 C 的类似更改，由完成上述链接文章的 Guy 开始。除其他有用的事实外，他们提出了一个似乎也适用于 C++0x 的解决方案（更新：这不再适用于 n3225 - 见下文！）

endless:
  goto endless;

不允许编译器优化该解决方案看起来，因为这不是循环，而是跳转。另一个人总结了 C++0x 和 C201X 中提议的更改

通过编写循环，程序员断言或者 循环执行一些具有可见行为的操作（执行 I/O、访问 易失性对象，或执行同步或原子操作）， 或者它最终终止。如果我违反了这个假设 通过编写一个没有副作用的无限循环，我对 编译器，并且我的程序的行为未定义。 （如果我幸运的话， 编译器可能会警告我。）该语言不提供 （不再提供？）一种表达无限循环的方法，无需 可见的行为。

---

2011 年 1 月 3 日更新 n3225：委员会将文本移至 1.10/24 并说

该实现可能假设任何线程最终都会执行以下操作之一：

• 终止，
• 调用库 I/O 函数，
• 访问或修改易失性对象，或者
• 执行同步操作或原子操作。

goto 技巧将不再起作用了！

Answer 1

对我来说，相关的理由是：

这是为了允许编译器进行转换，例如删除空循环，即使无法证明终止也是如此。

据推测，这是因为机械地证明终止是困难，并且无法证明终止会妨碍编译器，否则编译器可以进行有用的转换，例如将非依赖操作从循环之前移动到循环之后，反之亦然，执行后-循环在一个线程中进行操作，而循环在另一个线程中执行，依此类推。如果没有这些转换，循环可能会在等待一个线程完成所述循环时阻塞所有其他线程。 （我宽松地使用“线程”来表示任何形式的并行处理，包括单独的 VLIW 指令流。）

编辑：愚蠢的示例：

while (complicated_condition()) {
    x = complicated_but_externally_invisible_operation(x);
}
complex_io_operation();
cout << "Results:" << endl;
cout << x << endl;

在这里，一个线程执行复杂的 io_操作，而另一个线程执行复杂的 io 操作会更快正在循环中进行所有复杂的计算。但是如果没有您引用的子句，编译器必须在进行优化之前证明两件事：1）complex_io_operation()不依赖于循环的结果，2) < em>循环将终止。证明 1) 非常容易，证明 2) 是停机问题。使用该子句，它可以假设循环终止并获得并行化胜利。

我还认为设计者认为生产代码中出现无限循环的情况非常罕见，通常是像事件驱动循环这样以某种方式访问​​ I/O 的情况。因此，他们悲观了罕见的情况（无限循环），转而支持优化更常见的情况（非无限，但难以机械地证明非无限循环）。

然而，这确实意味着学习示例中使用的无限循环将因此受到影响，并且会在初学者代码中引发陷阱。我不能说这完全是一件好事。

编辑：关于您现在链接的富有洞察力的文章，我想说“编译器可能假设 X 关于程序”在逻辑上相当于“如果程序不满足 X，则行为未定义”。我们可以这样表示：假设存在一个不满足属性X的程序。该程序的行为在哪里定义？标准仅定义假设属性 X 为 true 的行为。尽管标准没有明确声明该行为未定义，但它已通过省略声明了该行为未定义。

考虑一个类似的论点：“编译器可能假设变量 x 在序列点之间最多只分配一次”相当于“在序列点之间多次分配给 x 是未定义的”。

Answer 2

有人可以很好地解释为什么有必要允许这样做吗？

是的，Hans Boehm 在 N1528 中对此提供了理由：为什么无限循环的行为未定义？，虽然这是 WG14 文档，但基本原理也适用于 C++，并且该文档同时引用了 WG14 和 WG21：

正如 N1509 正确指出的那样，当前草案基本上给出了
6.8.5p6 中无限循环的未定义行为。一个主要问题是
这样做的目的是它允许代码跨潜在的
非终止循环。例如，假设我们有以下循环，
其中 count 和 count2 是全局变量（或者有它们的地址
已取），p是局部变量，其地址尚未被取：

for (p = q; p != 0; p = p -> next) {
    ++计数；
}
for (p = q; p != 0; p = p -> 下一个) {
    ++计数2；
}

这两个循环可以合并并用下面的循环代替吗？

for (p = q; p != 0; p = p -> next) {
        ++计数；
        ++计数2；
}

如果没有 6.8.5p6 中针对无限循环的特殊分配，这
将被禁止：如果第一个循环没有终止，因为 q
指向一个循环列表，原始列表永远不会写入count2。因此
它可以与访问或的另一个线程并行运行
更新计数2。对于转换后的版本来说，这不再安全
尽管存在无限循环，但它确实访问了 count2 。因此
转型可能会引发数据竞争。

在这种情况下，编译器不太可能能够
证明循环终止；它必须明白 q 点
到一个非循环列表，我相信这超出了大多数人的能力
主流编译器，如果没有整个程序通常是不可能的
信息。

非终止循环施加的限制是对
优化编译器无法终止的循环
证明终止，以及实际的优化
非终止循环。前者比后者更常见
后者，通常优化起来更有趣。

显然也存在带有整数循环变量的 for 循环
编译器很难证明终止，并且
因此编译器很难重组循环
没有 6.8.5p6。甚至类似

for (i = 1; i != 15; i += 2)

或

for (i = 1; i <= 10; i += j)

处理起来似乎并不简单。 （在前一种情况下，一些基本数字
需要理论来证明终止，在后一种情况下，我们需要
了解 j 的可能值。环绕式
对于无符号整数可能会使某些推理进一步复杂化。）

这个问题似乎适用于几乎所有循环重组
转换，包括编译器并行化和
缓存优化转换，两者都有可能获得
的重要性，并且对于数字代码来说通常已经很重要。
这似乎可能会变成一笔巨大的成本
能够以最自然的方式编写无限循环，
特别是因为我们大多数人很少故意编写无限循环。

与 C 的一个主要区别是 C11 为控制常量表达式的表达式提供了例外，这与 C++ 不同，并且使您的C11 中明确定义了具体示例。

Trivial 无限循环不再是 C++ 中的 UB

随着 2024 年 3 月东京 ISO C++ 委员会会议通过 P2809， 。简单的无限循环不再是 C++ 中未定义的行为。

这并没有改变答案的本质，但确实使 C++ 与 C 更加一致。它允许用户使用大多数人认为惯用的无限循环安全性。

Answer 3

我认为正确的解释是您编辑的解释：空的无限循环是未定义的行为。

我不会说这是特别直观的行为，但这种解释比另一种解释更有意义，即编译器可以任意允许忽略无限循环而不调用 UB。

如果无限循环是 UB，则仅意味着非终止程序不被认为是有意义的：根据 C++0x，它们没有没有语义。

这确实也有一定的道理。它们是一种特殊情况，其中许多副作用不再发生（例如，main 不返回任何内容），并且许多编译器优化因必须保留无限循环而受到阻碍。例如，如果循环没有副作用，则跨循环移动计算是完全有效的，因为最终，计算将在任何情况下执行。
但是，如果循环永远不会终止，我们就无法安全地重新排列循环中的代码，因为我们可能只是更改在程序挂起之前实际执行的操作。除非我们将挂起的程序视为 UB，否则就是这样。

Answer 4

相关问题是编译器可以对副作用不冲突的代码进行重新排序。即使编译器为无限循环生成非终止机器代码，也可能会出现令人惊讶的执行顺序。

我相信这是正确的做法。语言规范定义了强制执行顺序的方法。如果您想要一个无法重新排序的无限循环，请编写以下内容：

volatile int dummy_side_effect;

while (1) {
    dummy_side_effect = 0;
}

printf("Never prints.\n");

Answer 5

我认为这符合这种类型的 问题，引用了另一个线程 。优化有时可以删除空循环。

Answer 6

我认为这个问题也许可以最好地表述为“如果后面的代码不依赖于前面的代码，并且前面的代码对系统的任何其他部分没有副作用，则编译器的输出可以在执行前一段代码之前、之后或与前一段代码混合执行后一段代码，即使前一段代码包含循环，而不考虑前一段代码何时或是否实际完成。 ，编译器可以重写：

void testfermat(int n)
{
  int a=1,b=1,c=1;
  while(pow(a,n)+pow(b,n) != pow(c,n))
  {
    if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++};
  }
  printf("The result is ");
  printf("%d/%d/%d", a,b,c);
}

as

void testfermat(int n)
{
  if (fork_is_first_thread())
  {
    int a=1,b=1,c=1;
    while(pow(a,n)+pow(b,n) != pow(c,n))
    {
      if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++};
    }
    signal_other_thread_and_die();
  }
  else // Second thread
  {
    printf("The result is ");
    wait_for_other_thread();
  }
  printf("%d/%d/%d", a,b,c);
}

一般不是不合理的，尽管我可能担心：

  int total=0;
  for (i=0; num_reps > i; i++)
  {
    update_progress_bar(i);
    total+=do_something_slow_with_no_side_effects(i);
  }
  show_result(total);

会变成

  int total=0;
  if (fork_is_first_thread())
  {
    for (i=0; num_reps > i; i++)
      total+=do_something_slow_with_no_side_effects(i);
    signal_other_thread_and_die();
  }
  else
  {
    for (i=0; num_reps > i; i++)
      update_progress_bar(i);
    wait_for_other_thread();
  }
  show_result(total);

通过让一个CPU处理计算，另一个处理进度条更新，重写会提高效率，不幸的是，它会使进度条更新。没有应有的用处。

Answer 7

有人可以很好地解释为什么有必要允许这样做吗？

我有一个解释为什么有必要不允许，假设 C++ 仍然有志成为一种适合性能关键的低级编程的通用语言。

这曾经是一个工作的、严格遵守的独立 C++ 程序：

int main()
{
  setup_interrupts();
  for(;;)
  {}
}

上面是在许多低端微控制器系统中编写 main() 的完美且常见的方法。整个程序执行在中断服务例程内完成（或者对于 RTOS，它可以是进程）。而且 main() 可能绝对不允许返回，因为这些是裸机系统，没有人可以返回。

可使用上述设计的典型现实示例包括 PWM/电机驱动器微控制器、照明控制应用、简单的调节器系统、传感器应用、简单的家用电子产品等。

不幸的是，C++ 的变化使得该语言无法用于此类嵌入式系统编程。如果移植到较新的 C++ 编译器，现有的实际应用程序（如上述应用程序）将会以危险的方式崩溃。

C++20 6.9.2.3 前进进度 [intro.progress]

该实现可能假设任何线程最终都会执行以下操作之一：
(1.1) — 终止，
(1.2) — 调用库 I/O 函数，
(1.3) — 通过易失性泛左值执行访问，或
(1.4) — 执行同步操作或原子操作。

让我们逐一讨论上述之前严格遵守的独立 C++ 程序：

• 1.1。正如任何嵌入式系统初学者都可以告诉委员会的那样，裸机/RTOS 微控制器系统永远不会终止。因此，循环不能终止，否则 main() 将变成失控代码，这将是严重且危险的错误情况。
• 1.2 不适用。
• 1.3 不一定。有人可能会争辩说，for(;;) 循环是喂养看门狗的正确位置，而这又是看门狗写入易失性寄存器时的副作用。但可能存在一些实现原因导致您不想使用看门狗。无论如何，规定应该使用看门狗并不是 C++ 的事。
• 1.4 不适用。

因此，C++ 比以前更不适合嵌入式系统应用程序。

---

这里的另一个问题是该标准谈到“线程”，这是更高层次的概念。在现实世界的计算机上，线程是通过称为中断的低级概念来实现的。中断在竞争条件和并发执行方面与线程类似，但它们不是线程。在低级系统上，只有一个核心，因此通常一次只执行一个中断（有点像过去在单核 PC 上工作的线程）。

如果不能有中断，就不能有线程。因此线程必须由比 C++ 更适合嵌入式系统的低级语言来实现。选项是汇编程序或 C。

---

通过编写循环，程序员可以断言循环执行一些具有可见行为的操作（执行 I/O、访问易失性对象或执行同步或原子操作），或者断言它最终终止。

这是完全误导的，并且是由从未使用过微控制器编程的人清楚地写的。

---

那么，那些“因为某些原因”拒绝将代码移植到 C 的少数剩余 C++ 嵌入式程序员应该做什么呢？您必须在 for(;;) 循环中引入副作用：

int main()
{
  setup_interrupts();
  for(volatile int i=0; i==0;)
  {}
}

或者，如果您按照应有的方式启用了看门狗，请将其输入到 for(;;) 中> 循环。

Answer 8

如果它根本是一个无限循环，那么对于非平凡情况，编译器是不可判定的。

在不同的情况下，您的优化器可能会为您的代码达到更好的复杂度级别（例如，它是 O(n^2)，优化后您将获得 O(n) 或 O(1)）。

因此，在 C++ 标准中包含这样一条不允许删除无限循环的规则将使许多优化变得不可能。大多数人不希望这样。我认为这完全回答了你的问题。

---

另一件事：我从未见过任何有效的示例，您需要一个不执行任何操作的无限循环。

我听说过的一个例子是一个丑陋的黑客行为，确实应该解决：它是关于嵌入式系统的，其中触发重置的唯一方法是冻结设备，以便看门狗自动重新启动它。

如果您知道任何有效/好的示例，您需要一个不执行任何操作的无限循环，请告诉我。

Answer 9

我认为值得指出的是，除了通过非易失性、非同步变量与其他线程交互这一事实之外，循环将是无限的，现在可以通过新编译器产生不正确的行为。

换句话说，使您的全局变量以及通过指针/引用传递到此类循环中的参数变得易失性。