C++编程语言第四版第225页写道：编译器可以重新排列代码以提高性能，只要结果与简单执行顺序的结果相同即可。一些编译器（如发布模式下的Visual C++）会重新排列此代码：
#include <time.h>
...
auto t0 = clock();
auto r = veryLongComputation();
auto t1 = clock();
std::cout << r << " time: " << t1-t0 << endl;
转换为这种形式：
auto t0 = clock();
auto t1 = clock();
auto r = veryLongComputation();
std::cout << r << " time: " << t1-t0 << endl;
这保证了与原始代码不同的结果（零与大于零的时间差）。请参见我的另一个问题以获得详细示例。这种行为是否符合C++标准？
嗯，C标准的第5.1.2.3款有一些内容指出：
在抽象机器中，所有表达式都按语义规定进行评估。如果实际实现可以推断出某个表达式的值未被使用并且没有产生任何必要的副作用（包括通过调用函数或访问易失对象引起的任何副作用），则无需评估该表达式的部分内容。
因此，我真的怀疑你所描述的这种行为是符合标准的。
此外-重组确实对计算结果有影响，但是从编译器的角度来看，它处于 int main() 的世界中，在进行时间测量时会露出来，请求内核提供当前时间，然后返回到主世界，此时外部世界的实际时间并不重要。clock()本身不会影响程序、变量和程序行为，程序的行为也不会影响 clock() 函数。
时钟值用于计算它们之间的差异-这就是你要求的。如果在两次测量之间发生了什么事情，则从编译器的角度来看并不重要，因为你要求的是时钟差异，而测量之间的代码不会影响测量过程。
然而，这并不能改变所描述的行为非常不愉快的事实。
尽管不准确的测量结果非常不愉快，但情况可能会更糟甚至更危险。
考虑下面从此网站中摘取的代码：
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {
if (ConnectToMainframe(MFAddr, pwd)) {
// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}
编译正常时，一切都好，但如果应用了优化，memset调用将被优化掉，这可能导致严重的安全漏洞。为什么它会被优化掉呢？很简单；编译器再次在其main()世界中思考，并认为由于变量pwd之后不再使用并且不会影响程序本身，因此memset是死代码。
pwd是易失性的，将其传递给memset会导致未定义的行为。您不能通过非易失性限定的左值访问易失性对象，这正是memset所做的。 - R.. GitHub STOP HELPING ICEstd::fill 可以使用。一个 volatile 指针仍然是迭代器。这证明了 C++ 并不比 C 更难预测。 - MSaltersclock调用，t1必须在t0之后设置。这两个调用都是可观察的副作用。编译器可以重新排序那些可观察副作用之间的任何内容，甚至覆盖可观察副作用，只要这些观察结果与抽象机器的可能观察结果一致即可。veryLongComputation()。执行时间本身不被定义为可观察效果，实际实现可以匹配它。是的，如果编译器可以看到在 clock() 调用之间发生的整个代码，则是合法的。
clock 的部分并不是被重新排序的 - 被重新排序的是计算部分。根据 as-if 规则，任何透明的计算都可以在任何时候进行计算。 - o11cveryLongComputation()不会引起任何可观察的行为。 - M.MveryLongComputation()内部执行任何不透明函数调用，则编译器无法保证其副作用与clock()的副作用可互换，因此不能互换。new）可能属于此类别，因为分配函数可以在不同的翻译单元中定义并且直到当前翻译单元已编译才进行编译。因此，如果仅分配内存，则编译器被迫将分配和释放视为一切的最坏情况障碍 - 包括 clock()，内存屏障和其他所有内容 - 除非它已经具有内存分配器的代码并且可以证明这是没有必要的。实际上，我认为没有编译器会查看分配器代码来尝试证明这一点，因此这些类型的函数调用在实践中充当屏障。cout写入的输出）是可观察行为。简短的答案是是的（§1.9/8）：clock仍然产生与按顺序执行调用相同的输出，则可以将其与您的长时间计算的执行重排。auto volatile t0 = clock();
auto volatile r = veryLongComputation();
auto volatile t1 = clock();
clock 的用法与长时间计算是明确被禁止的。请注意保留 HTML 标签。sleep 当然例外）。抽象机器设置了允许的结果范围，而不是一些“未优化”的构建。 - MSalters这绝对是不允许的，因为正如您所指出的那样，它会改变程序的可观察行为（产生不同的输出）。我不会进入假设情况，即veryLongComputation()可能不消耗任何可测量的时间--鉴于函数的名称，这可能不是真实情况。但即使是这种情况，也并不重要。您也不会期望可以重新排列fopen和fwrite，对吧。
在输出 t1-t0 中，t0 和 t1 都被使用。因此，对于两者的初始化表达式必须执行，并且执行必须遵循所有标准规则。虽然函数调用的结果被使用，但它不能被优化掉，尽管它不是直接依赖于 t1 或反之亦然，所以人们可能天真地认为它可以随意移动，为什么不呢？也许是在并未依赖于计算的情况下进行了 t1 的初始化？
然而，间接地，t1 的结果当然取决于 veryLongComputation() 的副作用（特别是计算需要时间等），这正是存在“序列点”这种东西的原因之一。
有三个“表达式结束”序列点（加上三个“函数结束”和“初始化器结束”的 SP），并且在每个序列点，保证之前的所有评估的副作用都已执行，并且尚未执行后续评估的任何副作用。
如果您移动这三个语句，就无法遵守此承诺，因为所有调用的函数的可能副作用是未知的。只有在编译器能够保证它会遵守承诺时，才允许进行优化。但是，由于库函数是不透明的，它们的代码不可用（veryLongComputation 中的代码也不一定在该翻译单元中已知）。
编译器有时会对库函数拥有“特殊知识”，例如某些函数不会返回或可能返回两次（考虑exit或setjmp）。但是，由于每个非空的、非平凡的函数（从其名称中可以看出，veryLongComputation是相当复杂的）都将消耗时间，因此编译器对于否则不透明的clock库函数具有“特殊知识”，实际上必须明确禁止在此调用周围重新排序调用，因为这样做不仅可能，而且一定会影响结果。
现在有趣的问题是，为什么编译器还要这样做呢？我能想到两种可能性。也许你的代码触发了“看起来像基准测试”的启发式算法，编译器试图欺骗，谁知道呢。这不是第一次了（想想SPEC2000/179.art或SunSpider这两个历史例子）。另一个可能性是，在veryLongComputation()内部的某个地方，您无意中调用了未定义的行为。在这种情况下，编译器的行为甚至是合法的。
veryLongComputation 的主体部分。MSVC具有链接时代码生成功能，这基本上意味着它可以看到该主体部分。 - MSaltersclock是可观察的（所有库调用都是）。不需要证明任何进一步的事情。而且，不，行为不需要与非优化版本完全相同。标准仅要求结果与抽象机器的可能结果之一相同，并且在一单位的time_t内运行肯定是可能的，因此是一个有效的结果。 - MSalters
g++ -O2 -S -fverbose-asm your-code.cc）。 - Basile StarynkevitchveryLongComputation()的调用可能会瞬间完成。 - Benjamin Lindley