問題描述

已更新，見下文！

我聽說并讀到 C++0x 允許編譯器為以下代碼段打印Hello"

I have heard and read that C++0x allows an compiler to print "Hello" for the following snippet

#include <iostream>

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

它顯然與線程和優(yōu)化能力有關(guān).不過在我看來，這會讓很多人感到驚訝.

It apparently has something to do with threads and optimization capabilities. It looks to me that this can surprise many people though.

有人對為什么有必要允許這樣做有很好的解釋嗎?作為參考，最新的 C++0x 草案在 6.5/5

Does someone have a good explanation of why this was necessary to allow? For reference, the most recent C++0x draft says at 6.5/5

一個循環(huán)，在 for 語句的情況下，在 for-init-statement 之外，

A loop that, outside of the for-init-statement in the case of a for statement,

• 不調(diào)用庫 I/O 函數(shù)，并且
• 不訪問或修改易失性對象，并且
• 不執(zhí)行同步操作 (1.10) 或原子操作(第 29 條)

可能由實現(xiàn)假設(shè)終止.[注意:這是為了允許編譯器轉(zhuǎn)換即使無法證明終止，也可以刪除空循環(huán).— 尾注 ]

may be assumed by the implementation to terminate. [ Note: This is intended to allow compiler transfor- mations, such as removal of empty loops, even when termination cannot be proven. — end note ]

這篇富有洞察力的文章介紹了該標準文本

不幸的是，沒有使用未定義行為"這個詞.然而，每當標準說編譯器可以假設(shè) P"時，就暗示具有非 P 屬性的程序具有未定義的語義.

Unfortunately, the words "undefined behavior" are not used. However, anytime the standard says "the compiler may assume P," it is implied that a program which has the property not-P has undefined semantics.

是否正確，是否允許編譯器為上述程序打印Bye"?

Is that correct, and is the compiler allowed to print "Bye" for the above program?

這里有一個更有見地的線程，這是對 C 的類似更改，由 Guy 開始，完成了上面鏈接的文章.在其他有用的事實中，他們提出了一個似乎也適用于 C++0x 的解決方案(更新:這將不再適用于 n3225 - 見下文！)

There is an even more insightful thread here, which is about an analogous change to C, started off by the Guy done the above linked article. Among other useful facts, they present a solution that seems to also apply to C++0x (Update: This won't work anymore with n3225 - see below!)

endless:
  goto endless;

似乎不允許編譯器將其優(yōu)化掉，因為它不是循環(huán)，而是跳轉(zhuǎn).另一個人總結(jié)了 C++0x 和 C201X 中提議的更改

A compiler is not allowed to optimize that away, it seems, because it's not a loop, but a jump. Another guy summarizes the proposed change in C++0x and C201X

通過編寫一個循環(huán)，程序員斷言要么循環(huán)執(zhí)行一些可見行為(執(zhí)行 I/O，訪問volatile 對象，或執(zhí)行同步或原子操作)，或它最終終止.如果我違反了那個假設(shè)通過編寫一個沒有副作用的無限循環(huán)，我在撒謊編譯器，我的程序的行為是未定義的.(如果我幸運的話，編譯器可能會警告我.)該語言不提供(不再提供?)一種表達無限循環(huán)的方法，而無需可見的行為.

By writing a loop, the programmer is asserting either that the loop does something with visible behavior (performs I/O, accesses volatile objects, or performs synchronization or atomic operations), or that it eventually terminates. If I violate that assumption by writing an infinite loop with no side effects, I am lying to the compiler, and my program's behavior is undefined. (If I'm lucky, the compiler might warn me about it.) The language doesn't provide (no longer provides?) a way to express an infinite loop without visible behavior.

<小時>

2011 年 1 月 3 日更新 n3225:委員會將文本移至 1.10/24 并說

Update on 3.1.2011 with n3225: Committee moved the text to 1.10/24 and say

該實現(xiàn)可能假設(shè)任何線程最終都會執(zhí)行以下操作之一:

The implementation may assume that any thread will eventually do one of the following:

• 終止，
• 調(diào)用庫 I/O 函數(shù)，
• 訪問或修改易失性對象，或
• 執(zhí)行同步操作或原子操作.

goto 技巧將不再工作！

推薦答案

有人對為什么有必要允許這樣做有很好的解釋嗎?

Does someone have a good explanation of why this was necessary to allow?

是的，Hans Boehm 在N1528:為什么無限循環(huán)的未定義行為?，雖然這是 WG14 文檔，但基本原理也適用于 C++，該文檔同時引用了 WG14 和 WG21:

Yes, Hans Boehm provides a rationale for this in N1528: Why undefined behavior for infinite loops?, although this is WG14 document the rationale applies to C++ as well and the document refers to both WG14 and WG21:

正如 N1509 正確指出的那樣，目前的草案基本上給出了6.8.5p6 中無限循環(huán)的未定義行為.一個主要問題這樣做是為了允許代碼在一個潛在的非終止循環(huán).例如，假設(shè)我們有以下循環(huán)，其中 count 和 count2 是全局變量(或有它們的地址取)，而p是局部變量，地址未被取:

As N1509 correctly points out, the current draft essentially gives undefined behavior to infinite loops in 6.8.5p6. A major issue for doing so is that it allows code to move across a potentially non-terminating loop. For example, assume we have the following loops, where count and count2 are global variables (or have had their address taken), and p is a local variable, whose address has not been taken:

for (p = q; p != 0; p = p -> next) {
    ++count;
}
for (p = q; p != 0; p = p -> next) {
    ++count2;
}

可以將這兩個循環(huán)合并并替換為以下循環(huán)嗎?

Could these two loops be merged and replaced by the following loop?

for (p = q; p != 0; p = p -> next) {
        ++count;
        ++count2;
}

沒有 6.8.5p6 中對無限循環(huán)的特殊規(guī)定，這將被禁止:如果第一個循環(huán)沒有終止，因為 q指向一個循環(huán)列表，原來從不寫入count2.因此它可以與另一個訪問或訪問的線程并行運行更新計數(shù)2.轉(zhuǎn)換后的版本不再安全盡管存在無限循環(huán)，但它確實訪問了 count2 .就這樣轉(zhuǎn)換可能會引入數(shù)據(jù)競爭.

Without the special dispensation in 6.8.5p6 for infinite loops, this would be disallowed: If the first loop doesn't terminate because q points to a circular list, the original never writes to count2. Thus it could be run in parallel with another thread that accesses or updates count2. This is no longer safe with the transformed version which does access count2 in spite of the infinite loop. Thus the transformation potentially introduces a data race.

在這種情況下，編譯器不太可能能夠證明循環(huán)終止；它必須明白 q 點到一個非循環(huán)列表，我認為這超出了大多數(shù)人的能力主流編譯器，如果沒有整個程序，通常是不可能的信息.

In cases like this, it is very unlikely that a compiler would be able to prove loop termination; it would have to understand that q points to an acyclic list, which I believe is beyond the ability of most mainstream compilers, and often impossible without whole program information.

非終止循環(huán)施加的限制是對編譯器無法執(zhí)行的終止循環(huán)的優(yōu)化證明終止，以及實際的優(yōu)化非終止循環(huán).前者比后者更常見后者，通常更有趣的是優(yōu)化.

The restrictions imposed by non-terminating loops are a restriction on the optimization of terminating loops for which the compiler cannot prove termination, as well as on the optimization of actually non-terminating loops. The former are much more common than the latter, and often more interesting to optimize.

顯然也有帶有整數(shù)循環(huán)變量的 for 循環(huán)編譯器很難證明終止，并且因此編譯器很難重構(gòu)循環(huán)沒有 6.8.5p6.甚至像

There are clearly also for-loops with an integer loop variable in which it would be difficult for a compiler to prove termination, and it would thus be difficult for the compiler to restructure loops without 6.8.5p6. Even something like

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

或

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

處理起來似乎很重要.(在前一種情況下，一些基本數(shù)字需要理論來證明終止，在后一種情況下，我們需要了解有關(guān) j 的可能值的一些信息.環(huán)繞式對于無符號整數(shù)可能會使某些推理進一步復(fù)雜化.)

seems nontrivial to handle. (In the former case, some basic number theory is required to prove termination, in the latter case, we need to know something about the possible values of j to do so. Wrap-around for unsigned integers may complicate some of this reasoning further.)

這個問題似乎適用于幾乎所有的循環(huán)重組轉(zhuǎn)換，包括編譯器并行化和緩存優(yōu)化轉(zhuǎn)換，這兩者都有可能獲得的重要性，并且對于數(shù)字代碼已經(jīng)很重要了.這似乎可能會轉(zhuǎn)化為巨大的成本能夠以最自然的方式編寫無限循環(huán)，尤其是因為我們大多數(shù)人很少故意編寫無限循環(huán).

This issue seems to apply to almost all loop restructuring transformations, including compiler parallelization and cache-optimization transformations, both of which are likely to gain in importance, and are already often important for numerical code. This appears likely to turn into a substantial cost for the benefit of being able to write infinite loops in the most natural way possible, especially since most of us rarely write intentionally infinite loops.

與 C 的一個主要區(qū)別是 C11 為控制常量表達式的表達式提供了一個例外，這與 C++ 不同并使您的具體示例在 C11 中得到明確定義.

The one major difference with C is that C11 provides an exception for controlling expressions that are constant expressions which differs from C++ and makes your specific example well-defined in C11.

這篇關(guān)于優(yōu)化掉一個“while(1);"在 C++0x的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！