c++ - "Observable behaviour"和编译器自由消除/转换 c++ 代码

Question

看完this discussion我意识到我几乎完全误解了这件事:)

由于对 C++ 抽象机的描述不够严格(例如，与 JVM 规范进行比较)，如果不可能得到准确的答案，我宁愿得到关于合理“好”的规则的非正式澄清(非恶意)实现应遵循。

标准第 1.9 部分的关键概念是实现自由，即所谓的假设规则:

an implementation is free to disregard any requirement of this Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program.

根据标准(我引用 n3092)，术语“可观察的行为”表示以下含义:

— Access to volatile objects are evaluated strictly according to the rules of the abstract machine.

— At program termination, all data written into files shall be identical to one of the possible results that execution of the program according to the abstract semantics would have produced.

— The input and output dynamics of interactive devices shall take place in such a fashion that prompting output is actually delivered before a program waits for input. What constitutes an interactive device is implementation-defined.

所以，大致来说，volatile访问操作和io操作的顺序和操作数应该被保留；实现可以在保留这些不变量的程序中进行任意更改(与抽象 c++ 机器的某些允许行为相比)

1. 期望非恶意实现足够广泛地处理 io 操作是否合理(例如，来自用户代码的任何系统调用都被视为此类操作)？ (例如，如果 RAII 包装器不包含 volatile，编译器不会丢弃 RAII 互斥锁/解锁)

2. “行为观察”应该从用户定义的 C++ 程序级别深入到库/系统调用中吗？当然，问题只是关于不打算从用户角度访问 io/volatile 的库调用(例如，作为新/删除操作)但可能(并且通常会)访问 volatile 或 io在库/系统实现中。编译器应该从用户的角度(并且将这些副作用视为不可观察)还是从“库”的角度(并将副作用视为可观察)来处理此类调用？

3. 如果我需要防止编译器消除某些代码，最好不要问上述所有问题并简单地添加(可能是假的) volatile 访问操作(将所需的操作包装到 volatile 方法并调用他们在我自己的类的 volatile 实例上)在任何看起来可疑的情况下？

4. 或者我完全错了，编译器不允许删除任何 c++ 代码，标准明确提到的情况除外(作为复制消除)

Answer 1

重要的是，编译器必须能够证明代码在删除之前没有副作用(或确定它有哪些副作用并用一些等效的部分替换它)代码)。一般来说，由于单独的编译模型，这意味着编译器在某种程度上受限于库调用具有可观察的行为并且可以被消除。

至于它的深度，它取决于库的实现。在 gcc 中，C 标准库使用编译器属性来通知编译器潜在的副作用(或没有副作用)。例如，strlen 带有 pure 属性标记，允许编译器转换此代码:

char p[] = "Hi there\n";
for ( int i = 0; i < strlen(p); ++i ) std::cout << p[i];

进入

char * p = get_string();
int __length = strlen(p);
for ( int i = 0; i < __length; ++i ) std::cout << p[i];

但是如果没有 pure 属性，编译器无法知道函数是否有副作用(除非它是内联它，并且可以看到 inside 函数)，并且无法进行上述优化。

也就是说，一般来说，编译器不会删除代码除非它可以证明它没有副作用，即不会影响程序的结果。请注意，这不仅与 volatile 和 io 有关，因为任何变量更改都可能在以后具有可观察的行为。

至于问题 3，只有当程序的行为与代码存在时完全相同(复制省略是一个异常(exception))，编译器才会删除您的代码，因此您甚至不必关心编译器是否将其删除。关于问题 4，as-if 规则是:如果编译器进行的隐式重构的结果产生相同的结果，则可以自由执行更改。考虑:

unsigned int fact = 1;
for ( unsigned int i = 1; i < 5; ++i ) fact *= i;

编译器可以自由地将代码替换为:

unsigned int fact = 120; // I think the math is correct... imagine it is

循环消失了，但行为是一样的:每次循环交互不影响程序的结果，并且变量在循环结束时具有正确的值，即如果以后在某些< em>observable 操作，结果将是 as-if 循环已被执行。

不要太担心 可观察行为 和 as-if 规则的含义，它们基本上意味着编译器必须产生您在您的程序中编写的输出代码，即使它可以自由地通过不同的路径获得该结果。

编辑

@Konrad 对我使用 strlen 的初始示例提出了一个非常好的观点:编译器如何知道 strlen 调用可以是省略？答案是在原始示例中它不能，因此它不能忽略调用。没有什么可以告诉编译器从 get_string() 函数返回的指针不引用正在其他地方修改的内存。我已将示例更正为使用本地数组。

在修改后的示例中，数组是本地的，编译器可以验证没有其他指针指向同一内存。 strlen 接受一个 const 指针，因此它 promise 不会修改包含的内存，并且该函数是 pure 因此它 promise 不会修改任何其他状态。数组在循环结构内没有被修改，编译器收集所有这些信息可以确定对 strlen 的单个调用就足够了。如果没有 pure 说明符，编译器无法知道 strlen 的结果是否会在不同的调用中有所不同，并且必须调用它。