实际上，为什么不同的编译器会计算int x = ++ i + ++ i;的不同值？

考虑以下代码：

int i = 1;
int x = ++i + ++i;

我们假设编译器对此代码可能进行编译时有一些猜测。

1. 两者都++i返回2，导致x=4。
2. 一个++i返回2，另一个返回3，导致x=5。
3. 两者都++i返回3，导致x=6。

在我看来，第二次出现的可能性最大。使用++运算符执行两个运算符之一i = 1，将i其递增，然后2返回结果。然后，使用++来执行第二个运算符i = 2，将i递增，并3返回结果。然后2与3加在一起得到5。

但是，我在Visual Studio中运行了这段代码，结果是6。我试图更好地理解编译器，并且想知道什么可能导致的结果6。我唯一的猜测是代码可以通过一些“内置”并发执行。++调用了两个运算符，每个运算符i在另一个返回之前先递增，然后都返回3。这将与我对调用堆栈的理解相矛盾，因此需要加以解释。

C++编译器可能会执行哪些（合理的）操作，从而导致结果4或结果或6？

注意

该示例在Bjarne Stroustrup的《编程：使用C ++的原理和实践》中作为未定义行为的示例出现。

参见肉桂的评论。

编译器将您的代码分成非常简单的指令，然后以它认为最佳的方式重新组合和排列它们。

编码

int i = 1;
int x = ++i + ++i;

由以下说明组成：

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
5. read i as tmp2
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

但是，尽管这是我编写方法的编号列表，但这里只有少数排序依存关系：1-> 2-> 3-> 4-> 5-> 10-> 11和1-> 6-> 7- > 8-> 9-> 10-> 11必须保持相对顺序。除此之外，编译器可以自由地重新排序，并可能消除冗余。

例如，您可以按以下顺序订购列表：

1. store 1 in i
2. read i as tmp1
6. read i as tmp3
3. add 1 to tmp1
7. add 1 to tmp3
4. store tmp1 in i
8. store tmp3 in i
5. read i as tmp2
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

为什么编译器可以这样做？因为增量的副作用没有排序。但是现在编译器可以简化：例如，在4中有一个死存储：该值立即被覆盖。另外，tmp2和tmp4确实是同一回事。

1. store 1 in i
2. read i as tmp1
6. read i as tmp3
3. add 1 to tmp1
7. add 1 to tmp3
8. store tmp3 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

现在，与tmp1有关的所有操作都是无效代码：从未使用过。而且我的重读也可以消除：

1. store 1 in i
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
10. add tmp3 and tmp3, as tmp5
11. store tmp5 in x

看，这段代码要短得多。优化器很高兴。程序员不是，因为我只增加了一次。哎呀。

让我们看看编译器可以做的其他事情：让我们回到原始版本。

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
5. read i as tmp2
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

编译器可以像这样重新排序：

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
5. read i as tmp2
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

然后再次注意，我被阅读了两次，因此消除其中之一：

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

很好，但是可以更进一步：它可以重用tmp1：

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
6. read i as tmp1
7. add 1 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

然后可以消除6中i的重读：

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
7. add 1 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

现在4已死：

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
7. add 1 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

现在3和7可以合并为一条指令：

1. store 1 in i
2. read i as tmp1
3+7. add 2 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

消除最后一个临时：

1. store 1 in i
2. read i as tmp1
3+7. add 2 to tmp1
8. store tmp1 in i
10. add tmp1 and tmp1, as tmp5
11. store tmp5 in x

现在，您得到了Visual C ++给您的结果。

请注意，在两个优化路径中，重要的顺序依赖性都得以保留，只要不删除指令就什么​​都不做即可。

虽然这是UB（如OP所示），但以下是编译器可以获取3个结果的假设方法。x如果与不同的int i = 1, j = 1;变量而不是一个相同的变量一起使用，这三个变量都会给出正确的结果i。

1. 两者++ i都返回2，导致x = 4。

int i = 1;
int i1 = i, i2 = i;   // i1 = i2 = 1
++i1;                 // i1 = 2
++i2;                 // i2 = 2
int x = i1 + i2;      // x = 4

2. 一个++ i返回2，另一个++ 3返回x = 5。

int i = 1;
int i1 = ++i;           // i1 = 2
int i2 = ++i;           // i2 = 3
int x = i1 + i2;        // x = 5

3. 两者++ i都返回3，导致x = 6。

int i = 1;
int &i1 = i, &i2 = i;
++i1;                   // i = 2
++i2;                   // i = 3
int x = i1 + i2;        // x = 6

在我看来，第二次出现的可能性最大。

我要选择选项4：两者++i同时发生。

较新的处理器朝着一些有趣的优化和并行代码评估迈进，这是编译器不断提高代码速度的另一种方式。我认为编译器向并行性迈进是一种实际的实现。

我很容易看到由于相同的内存争用而导致的争用情况导致不确定的行为或总线故障-由于编码器违反了C ++合同，因此全部允许-因此UB。

我的问题是：C ++编译器可以执行哪些（合理的）操作，导致结果为4或结果为6？

它可以，但不计入其中。

不要使用++i + ++i也不期望有明智的结果。

我认为，简单明了的解释（无需对编译器优化或多线程进行任何尝试）就是：

1. 增量 i
2. 增量 i
3. 添加i+i

用i递增两次，它的值是3，并且当加在一起时，和为6。

为了进行检查，请将其视为C ++函数：

int dblInc ()
{
    int i = 1;
    int x = ++i + ++i;
    return x;   
}

现在，这是我使用旧版本的GNU C ++编译器（win32，gcc版本3.4.2（mingw-special））通过编译该函数获得的汇编代码。这里没有花哨的优化或多线程发生：

__Z6dblIncv:
    push    ebp
    mov ebp, esp
    sub esp, 8
    mov DWORD PTR [ebp-4], 1
    lea eax, [ebp-4]
    inc DWORD PTR [eax]
    lea eax, [ebp-4]
    inc DWORD PTR [eax]
    mov eax, DWORD PTR [ebp-4]
    add eax, DWORD PTR [ebp-4]
    mov DWORD PTR [ebp-8], eax
    mov eax, DWORD PTR [ebp-8]
    leave
    ret

请注意，局部变量i仅位于一个位置的堆栈上：address [ebp-4]。该位置增加了两次（在汇编函数的第5-8行中；包括该地址中显然有的冗余负载eax）。然后在第9-10行，将该值加载到中eax，然后添加到中eax（即，计算当前i + i）。然后将其冗余复制到堆栈中，并eax作为返回值返回（显然将为6）。

查看C ++标准（此处为旧标准：ISO / IEC 14882：1998（E））可能会对您有所帮助，该标准在“表达式”第5.4节中说：

除非另有说明，否则未指定各个运算符的操作数和各个表达式的子表达式的求值顺序以及发生副作用的顺序。

带有脚注：

运算符的优先级不是直接指定的，但是可以从语法中得出。

此时给出了两个未指定行为的示例，都涉及增量运算符（其中一个是：）i = ++i + 1。

现在，如果愿意，可以：创建一个整数包装器类（如Java Integer）；重载函数operator+，operator++以便它们返回中间值对象；从而编写++iObj + ++iObj并获取它以返回一个持有5的对象。（为了简洁起见，此处未包含完整的代码。）

就个人而言，我很感兴趣是否有一个著名的编译器示例，该示例以上述顺序以外的任何其他方式完成了该工作。在我看来，最直接的实现inc是在执行加法运算之前仅对原始类型执行两个汇编代码。

编译器可以做的合理的事情是Common Subexpression Elimination。这已经是编译器中的常见优化：如果子表达式(x+1)在较大的表达式中多次出现，则只需要计算一次即可。例如，在a/(x+1) + b*(x+1)该x+1子表达式可以计算一次。

当然，编译器必须知道可以通过这种方式优化哪些子表达式。拨打rand()两次应给两个随机数。因此，非内联函数调用必须免于CSE。正如您所注意到的，没有规则说明i++应如何处理两次出现的情况，因此没有理由将其从CSE中豁免。

结果可能确实int x = ++i + ++i;是优化为int __cse = i++; int x = __cse << 1。（CSE，然后反复降低强度）

实际上，您正在调用未定义的行为。任何事情都有可能发生，不只是东西，你认为“合理”，而且往往事情就发生，你不考虑合理。按照定义，一切都是“合理的”。

一个非常合理的编译是，编译器观察到执行一条语句将调用未定义的行为，因此该语句无法执行，因此将其翻译为一条指令，有意使您的应用程序崩溃。那是很合理的。

下载者：GCC非常反对您。

有没有合理的事情编译器能做得到的6的结果，但它是可能的，合法的。4的结果是完全合理的，我认为5边界的结果是合理的。所有这些都是完全合法的。

嘿，等等！不清楚会发生什么吗？加法需要两个增量的结果，因此显然这些必须首先发生。我们从左到右走，所以...啊！如果只是那么简单。不幸的是，事实并非如此。我们不会从左到右走，这就是问题所在。

对于编译器来说，将内存位置读取到两个寄存器中（或从相同的文字初始化它们，优化往返内存）是一件非常合理的事情。这将有效地具有有隐蔽在两个效果不同的变量，每个具有2的值，这将最终被添加到为4的结果。这是“合理的”，因为它是快速和有效的，而且它是根据两个标准和代码。

类似地，该存储位置可以被读取一次（或从立即数初始化的变量）并增加一次，此后可以递增另一个寄存器中的卷影副本，这将导致2和3加在一起。我认为这是合理的边界，尽管完全合法。我认为这是合理的，因为它不是一个。它既不是“合理的”优化方法，也不是“合理的”完全学究的方法。它有点在中间。

将内存位置增加两次（结果为3），然后将该值加到自身以得到最终结果6，这是合理的，但由于进行内存往返并不十分有效，因此不太合理。尽管在具有良好存储转发功能的处理器上，这样做也可能是“合理的”，因为存储应该基本上是不可见的...
当编译器“知道”它位于相同的位置时，它也可能选择递增在寄存器中将该值两次，然后再将其添加到自身。两种方法都可以得到6的结果。

按照标准的措辞，编译器可以为您提供任何这样的结果，尽管我个人认为6是Obnoxious Department的“ fuck you”备忘录，因为这是相当意外的事情（无论是否合法，尝试总是给自己最少的惊喜是一件好事！）。尽管看到未定义行为是如何涉及的，可悲的是，人们不能真正争论“意外”，嗯。

那么，实际上，您在编译器中拥有的代码是什么？让我们问一声clang，它将向我们展示我们是否做得很好（调用-ast-dump -fsyntax-only）：

ast.cpp:4:9: warning: multiple unsequenced modifications to 'i' [-Wunsequenced]
int x = ++i + ++i;
        ^     ~~
(some lines omitted)
`-CompoundStmt 0x2b3e628 <line:2:1, line:5:1>
  |-DeclStmt 0x2b3e4b8 <line:3:1, col:10>
  | `-VarDecl 0x2b3e430 <col:1, col:9> col:5 used i 'int' cinit
  |   `-IntegerLiteral 0x2b3e498 <col:9> 'int' 1
  `-DeclStmt 0x2b3e610 <line:4:1, col:18>
    `-VarDecl 0x2b3e4e8 <col:1, col:17> col:5 x 'int' cinit
      `-BinaryOperator 0x2b3e5f0 <col:9, col:17> 'int' '+'
        |-ImplicitCastExpr 0x2b3e5c0 <col:9, col:11> 'int' <LValueToRValue>
        | `-UnaryOperator 0x2b3e570 <col:9, col:11> 'int' lvalue prefix '++'
        |   `-DeclRefExpr 0x2b3e550 <col:11> 'int' lvalue Var 0x2b3e430 'i' 'int'
        `-ImplicitCastExpr 0x2b3e5d8 <col:15, col:17> 'int' <LValueToRValue>
          `-UnaryOperator 0x2b3e5a8 <col:15, col:17> 'int' lvalue prefix '++'
            `-DeclRefExpr 0x2b3e588 <col:17> 'int' lvalue Var 0x2b3e430 'i' 'int'

如您所见，相同的lvalue Var 0x2b3e430前缀++在两个位置应用，并且这两个前缀在树中的同一节点之下，这恰好是一个非常特殊的运算符（+），对序列等没有特别说明。为什么这很重要？好吧，继续读下去。

请注意以下警告：“对i进行了多个无序的修改”。哦，听起来不好。这是什么意思？[basic.exec]告诉我们有关副作用和排序的信息，并且告诉我们（第10段），默认情况下，除非另有明确说明，否则对单个运算符的操作数和各个表达式的子表达式的求值是无序列的。好吧，该死的就是这样operator+-别无其他说法，所以...

但是，我们是否关心先序列，不确定序列或未序列？谁想知道？

同一段还告诉我们，未排序的求值可能会重叠，并且当它们引用相同的内存位置时（就是这种情况！），并且该值不是潜在的并发，则行为是不确定的。这是真正的丑陋之处，因为那意味着您一无所知，也无法保证自己“合理”。不合理的事情实际上是完全可以容许和“合理的”。

有一条规则：

在上一个序列点与下一个序列点之间，一个标量对象最多必须通过表达式的求值修改其存储值，否则行为是不确定的。

因此，即使x = 100也是可能的有效结果。

对我而言，该示例中最合乎逻辑的结果是6，因为我们将i的值增加了两倍，并且它们将其加到了自身上。在“ +”的两边计算值之前很难进行加法运算。

但是编译器开发人员可以实现任何其他逻辑。

看起来++ i返回左值，但是i ++返回右值。
这样的代码就可以了：

int i = 1;
++i = 10;
cout << i << endl;

这不是：

int i = 1;
i++ = 10;
cout << i << endl;

以上两个语句与VisualC ++，GCC7.1.1，CLang和Embarcadero一致。
这就是为什么您在VisualC ++和GCC7.1.1中的代码类似于以下代码的原因

int i = 1;
... do something there for instance: ++i; ++i; ...
int x = i + i;

查看反汇编时，它首先递增i，然后重写i。尝试添加时，它执行相同的操作，将i递增并重写。然后将我添加到我。 我注意到CLang和Embarcadero的行为有所不同。因此，它与第一个语句不一致，在第一个++ i之后，它将结果存储在一个右值中，然后将其添加到第二个i ++中。

我个人绝不会期望编译器在您的示例中输出6。您的问题已经有很好且详细的答案。我会尝试一个简短的版本。

++i在这种情况下，基本上是一个两步过程：

1. 增值 i
2. 读取的值 i

在添加的++i + ++i两个方面，可以根据标准以任何顺序评估添加。这意味着这两个增量被认为是独立的。而且，两个术语之间没有依赖性。因此，增量和读取i可以交错。这给出了潜在的顺序：

1. i左操作数的增量
2. i正确的操作数的增量
3. 读回i左操作数
4. 读回i正确的操作数
5. 两者之和：收益6

现在，我考虑一下，按照标准，6是最有意义的。对于4的结果，我们需要一个CPU，该CPU首先i独立读取，然后递增并将该值写回到同一位置。基本上是比赛条件 对于5值，我们需要一个引入临时变量的编译器。

但是，该标准说++i在返回变量之前（即在实际执行当前代码行之前）先递增变量。求和运算符+需要i + i在应用增量后求和。我想说C ++需要处理变量而不是值语义。因此，对我来说6是最有意义的，因为它依赖于语言的语义而不是CPU的执行模型。

#include <stdio.h>


void a1(void)
{
    int i = 1;
    int x = ++i;
    printf("i=%d\n",i);
    printf("x=%d\n",x);
    x = x + ++i;    // Here
    printf("i=%d\n",i);
    printf("x=%d\n",x);
}


void b2(void)
{
    int i = 1;
    int x = ++i;
    printf("i=%d\n",i);
    printf("x=%d\n",x);
    x = i + ++i;    // Here
    printf("i=%d\n",i);
    printf("x=%d\n",x);
}


void main(void)
{
    a1();
    // b2();
}

因为答案取决于编译器解码语句的方式。使用两个不同的变量++ x和++ y来创建逻辑是一个更好的选择。注意：输出取决于ms visual Studio中语言的最新版本（如果已更新），因此如果规则已更改，则输出也将更改

尝试这个

int i = 1;
int i1 = i, i2 = i;   // i1 = i2 = 1
++i1;                 // i1 = 2
++i2;                 // i2 = 2
int x = i1 + i2;      // x = 4

从此评估链接顺序：

未指定任何C运算符的操作数的求值顺序，包括函数调用表达式中的函数参数的求值顺序，以及任何表达式中的子表达式的求值顺序（以下说明除外）。编译器将按任何顺序对它们进行求值，并在再次求同一个表达式时可以选择其他顺序。

从引号可以明显看出，评估顺序未由C标准指定。不同的编译器执行不同的评估顺序。编译器可以自由地以任何顺序求值此类表达式。这就是为什么不同的编译器为问题中提到的表达式提供不同的输出的原因。

但是，如果在子表达式Exp1和Exp2之间存在序列点，则在计算Exp2的每个值和副作用之前，先对Exp1的值计算和副作用进行排序。

实际上，您正在调用未定义的行为。任何事情都有可能发生，不只是东西，你认为“合理”，而且往往事情就发生，你不考虑合理。按照定义，一切都是“合理的”。

一个非常合理的编译是，编译器发现执行一条语句将调用未定义的行为，因此该语句无法执行，因此将其翻译为一条指令，有意使您的应用程序崩溃。那是很合理的。毕竟，编译器知道这种崩溃永远不会发生。