为什么这些构造使用增量前和增量后未定义的行为？
#include <stdio.h>
int main(void)
{
int i = 0;
i = i++ + ++i;
printf("%d\n", i); // 3
i = 1;
i = (i++);
printf("%d\n", i); // 2 Should be 1, no ?
volatile int u = 0;
u = u++ + ++u;
printf("%d\n", u); // 1
u = 1;
u = (u++);
printf("%d\n", u); // 2 Should also be one, no ?
register int v = 0;
v = v++ + ++v;
printf("%d\n", v); // 3 (Should be the same as u ?)
int w = 0;
printf("%d %d\n", ++w, w); // shouldn't this print 1 1
int x[2] = { 5, 8 }, y = 0;
x[y] = y ++;
printf("%d %d\n", x[0], x[1]); // shouldn't this print 0 8? or 5 0?
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
C 具有未定义行为的概念，即某些语言结构在语法上是有效的，但您无法预测代码运行时的行为。
据我所知，该标准没有明确说明为什么存在未定义行为的概念。在我看来，这只是因为语言设计者希望在语义上有一些余地，而不是要求所有实现都以完全相同的方式处理整数溢出，这很可能会带来严重的性能成本，他们只是留下了行为未定义，因此如果您编写的代码导致整数溢出，任何事情都可能发生。
那么，考虑到这一点，为什么会出现这些“问题”呢？该语言清楚地表明某些事情会导致未定义行为。没有问题，不存在“应该”的问题。如果在声明所涉及的变量之一时未定义的行为发生变化
易失性，则不会证明或改变任何内容。它是未定义；你无法推理该行为。您最有趣的示例
是未定义行为的教科书示例（请参阅维基百科的条目 sequence点）。
C has the concept of undefined behavior, i.e. some language constructs are syntactically valid but you can't predict the behavior when the code is run.
As far as I know, the standard doesn't explicitly say why the concept of undefined behavior exists. In my mind, it's simply because the language designers wanted there to be some leeway in the semantics, instead of i.e. requiring that all implementations handle integer overflow in the exact same way, which would very likely impose serious performance costs, they just left the behavior undefined so that if you write code that causes integer overflow, anything can happen.
So, with that in mind, why are these "issues"? The language clearly says that certain things lead to undefined behavior. There is no problem, there is no "should" involved. If the undefined behavior changes when one of the involved variables is declared
volatile, that doesn't prove or change anything. It is undefined; you cannot reason about the behavior.Your most interesting-looking example, the one with
is a text-book example of undefined behavior (see Wikipedia's entry on sequence points).
这里的大多数答案都引用了 C 标准，强调这些构造的行为是未定义的。要理解为什么这些构造的行为未定义，我们首先根据 C11 标准来理解这些术语：
顺序： (5.1.2.3)
未排序：
评估可以是以下两种情况之一：
序列点：
现在回到问题，对于像
标准这样的表达式：
6.5 表达式：
因此，上述表达式调用 UB，因为同一对象
i上的两个副作用相对于彼此是无序的。这意味着分配给i的副作用是在++的副作用之前还是之后完成，并没有排序。根据分配发生在增量之前还是之后，将会产生不同的结果，这就是未定义行为的情况之一。
让我们将赋值左侧的
i重命名为il，将赋值右侧（在表达式i++中）重命名为ir，那么表达式就像关于 Postfix
++运算符的重要一点是：这意味着表达式
il = ir++可以被计算为或
产生两个不同的结果
1和2，这取决于副作用的顺序通过赋值和++，因此调用未定义的行为。Most of the answers here quoted from C standard emphasizing that the behaviour of these constructs are undefined. To understand why the behaviour of these constructs are undefined, let's understand these terms first in the light of C11 standard:
Sequenced: (5.1.2.3)
Unsequenced:
Evaluations can be one of two things:
Sequence Point:
Now coming to the question, for the expressions like
standard says that:
6.5 Expressions:
Therefore, the above expression invokes UB because two side effects on the same object
iis unsequenced relative to each other. That means it is not sequenced whether the side effect by assignment toiwill be done before or after the side effect by++.Depending on whether assignment occurs before or after the increment, different results will be produced and that's the one of the case of undefined behaviour.
Lets rename the
iat left of assignment beiland at the right of assignment (in the expressioni++) beir, then the expression be likeAn important point regarding Postfix
++operator is that:It means the expression
il = ir++could be evaluated either asor
resulting in two different results
1and2which depends on the sequence of side effects by assignment and++and hence invokes undefined behaviour.我认为C99标准的相关部分是6.5表达式，§2
和 6.5.16 赋值运算符，§4：
I think the relevant parts of the C99 standard are 6.5 Expressions, §2
and 6.5.16 Assignment operators, §4:
只要编译和反汇编你的代码行，如果你很想知道它到底是如何得到你所得到的。
这是我在我的机器上得到的，以及我认为正在发生的事情：（
我......假设 0x00000014 指令是某种编译器优化？）
Just compile and disassemble your line of code, if you are so inclined to know how exactly it is you get what you are getting.
This is what I get on my machine, together with what I think is going on:
(I... suppose that the 0x00000014 instruction was some kind of compiler optimization?)
该行为无法真正解释，因为它同时调用 未指定行为 和 未定义行为，因此我们无法对此代码做出任何一般性预测，尽管如果您阅读Olve Maudal 的作品，例如 Deep C 和 未指定和未定义 有时，您可以在非常具体的情况下使用特定的内容做出很好的猜测编译器和环境，但请不要在生产附近这样做。
因此，继续讨论
因此，当我们有这样一行时：
我们不知道首先评估的是
i++还是++i。这主要是为了给编译器更好的优化选项。我们这里也有未定义的行为，因为程序在i、
u等..） href="http://en.wikipedia.org/wiki/Sequence_point" rel="noreferrer">序列点。来自草案标准部分6.5段落 2（强调我的）：它引用了以下未定义的代码示例：
在所有这些示例中，代码尝试在同一序列点中多次修改对象，在每种情况下都会以
;结尾：未指定的行为在c99 标准草案 在
3.4.4部分如下：和未定义行为在
3.4.3节中定义为：，并指出：
The behavior can't really be explained because it invokes both unspecified behavior and undefined behavior, so we can not make any general predictions about this code, although if you read Olve Maudal's work such as Deep C and Unspecified and Undefined sometimes you can make good guesses in very specific cases with a specific compiler and environment but please don't do that anywhere near production.
So moving on to unspecified behavior, in draft c99 standard section
6.5paragraph 3 says(emphasis mine):So when we have a line like this:
we do not know whether
i++or++iwill be evaluated first. This is mainly to give the compiler better options for optimization.We also have undefined behavior here as well since the program is modifying variables(
i,u, etc..) more than once between sequence points. From draft standard section6.5paragraph 2(emphasis mine):it cites the following code examples as being undefined:
In all these examples the code is attempting to modify an object more than once in the same sequence point, which will end with the
;in each one of these cases:Unspecified behavior is defined in the draft c99 standard in section
3.4.4as:and undefined behavior is defined in section
3.4.3as:and notes that:
回答这个问题的另一种方法，不是陷入序列点和未定义行为的神秘细节中，而是简单地问，它们应该意味着什么？ 程序员试图做什么？
第一个询问的片段，
i = i++ + ++i，在我的书中显然很疯狂。没有人会在真实的程序中编写它，它的作用并不明显，没有任何人可以想象的算法可以尝试编码来导致这种特定的人为操作序列。由于你我都不清楚它应该做什么，所以在我的书中，如果编译器无法弄清楚它应该做什么也没关系。第二个片段
i = i++更容易理解一些。看起来有人试图递增i，并将结果分配回i。但在 C 语言中，有几种方法可以实现此目的。获取 i 的值，加 1，然后将结果赋回 i 的最基本方法是：几乎所有编程语言都一样：当然，C 有一个方便的快捷方式：
这也意味着“取
i的值，加 1，然后将结果赋回给i代码>”。因此，如果我们构建两者的大杂烩，通过编写我们真正要说的是“取
i的值，加 1，将结果分配回i，并将结果分配回i”。我们很困惑，所以如果编译器也很困惑，我也不会太担心。实际上，只有当人们将它们用作
++应该如何工作的人工示例时，才会编写这些疯狂的表达式。当然，了解++的工作原理也很重要。但使用++的一条实用规则是，“如果使用++的表达式的含义不明显，则不要编写它。”我们过去常常在 comp.lang.c 上花费无数时间讨论这些表达式以及为什么它们未定义。我的两个较长的答案试图真正解释原因，已在网络上存档：
另请参阅问题 3.8 以及其余问题在第 3 节中。 com/" rel="nofollow noreferrer">C 常见问题列表。
Another way of answering this, rather than getting bogged down in arcane details of sequence points and undefined behavior, is simply to ask, what are they supposed to mean? What was the programmer trying to do?
The first fragment asked about,
i = i++ + ++i, is pretty clearly insane in my book. No one would ever write it in a real program, it's not obvious what it does, there's no conceivable algorithm someone could have been trying to code that would have resulted in this particular contrived sequence of operations. And since it's not obvious to you and me what it's supposed to do, it's fine in my book if the compiler can't figure out what it's supposed to do, either.The second fragment,
i = i++, is a little easier to understand. It looks like someone is trying to incrementi, and assign the result back toi. But there are a couple ways of doing this in C. The most basic way to takei's value, add 1, and assign the result back toi, is the same in almost any programming language:C, of course, has a handy shortcut:
This also means, "take
i's value, add 1, and assign the result back toi". So if we construct a hodgepodge of the two, by writingwhat we're really saying is "take
i's value, add 1, assign the result back toi, and assign the result back toi". We're confused, so it doesn't bother me too much if the compiler gets confused, too.Realistically, the only time these crazy expressions get written is when people are using them as artificial examples of how
++is supposed to work. And of course it is important to understand how++works. But one practical rule for using++is, "If it's not obvious what an expression using++means, don't write it."We used to spend countless hours on comp.lang.c discussing expressions like these and why they're undefined. Two of my longer answers, that try to really explain why, are archived on the web:
See also question 3.8 and the rest of the questions in section 3 of the C FAQ list.
类似变体相关的问题的重复链接
通常，此问题会作为与类似代码或
。
虽然这也是未定义行为，如前所述，但存在细微差别当与以下语句进行比较时涉及
printf()时：在以下语句中：
printf() 中参数的rel="noreferrer">求值顺序是未指定。这意味着表达式
i++和++i可以按任意顺序求值。 C11标准对此有一些相关描述：Annex J，未指定行为
3.4.4、未指定行为
未指定的行为本身不是问题。考虑这个例子：
这也有未指定的行为，因为
++x和y++的计算顺序未指定。但这是完全合法有效的声明。此语句中没有未定义的行为。因为修改（++x和y++）是针对不同的对象进行的。使以下语句呈现
为未定义行为的事实是，这两个表达式修改相同对象
i，而无需介入序列点。另一个细节是 printf() 调用中涉及的逗号是一个分隔符，而不是逗号运算符。
这是一个重要的区别，因为逗号运算符确实在其操作数的计算之间引入了序列点，这使得以下内容合法：
逗号运算符从左到右计算其操作数-right 并且仅产生最后一个操作数的值。因此，在
j = (++i, i++);中，++i将i递增到6并且 < code>i++ 产生i(6) 的旧值，该值被分配给j。然后由于后自增，i变为7。因此，如果函数调用中的逗号是逗号运算符，那么
就不会出现问题。但它会调用未定义的行为，因为这里的逗号是一个分隔符。
对于那些刚接触未定义行为的人来说，阅读每个 C 程序员都应该了解未定义行为，以了解 C 中未定义行为的概念和许多其他变体。
这篇文章：未定义、未指定和实现定义的行为也相关。
Often this question is linked as a duplicate of questions related to code like
or
or similar variants.
While this is also undefined behaviour as stated already, there are subtle differences when
printf()is involved when comparing to a statement such as:In the following statement:
the order of evaluation of arguments in
printf()is unspecified. That means, expressionsi++and++icould be evaluated in any order. C11 standard has some relevant descriptions on this:Annex J, unspecified behaviours
3.4.4, unspecified behavior
The unspecified behaviour itself is NOT an issue. Consider this example:
This too has unspecified behaviour because the order of evaluation of
++xandy++is unspecified. But it's perfectly legal and valid statement. There's no undefined behaviour in this statement. Because the modifications (++xandy++) are done to distinct objects.What renders the following statement
as undefined behaviour is the fact that these two expressions modify the same object
iwithout an intervening sequence point.Another detail is that the comma involved in the printf() call is a separator, not the comma operator.
This is an important distinction because the comma operator does introduce a sequence point between the evaluation of their operands, which makes the following legal:
The comma operator evaluates its operands left-to-right and yields only the value of the last operand. So in
j = (++i, i++);,++iincrementsito6andi++yields old value ofi(6) which is assigned toj. Thenibecomes7due to post-increment.So if the comma in the function call were to be a comma operator then
will not be a problem. But it invokes undefined behaviour because the comma here is a separator.
For those who are new to undefined behaviour would benefit from reading What Every C Programmer Should Know About Undefined Behavior to understand the concept and many other variants of undefined behaviour in C.
This post: Undefined, unspecified and implementation-defined behavior is also relevant.
虽然任何编译器和处理器实际上不太可能这样做，但根据 C 标准，编译器使用以下序列实现“i++”是合法的：
虽然我不认为任何处理器支持允许这样的硬件一件需要高效完成的事情，人们可以很容易地想象这种行为将使多线程代码变得更容易的情况（例如，它将保证如果两个线程尝试同时执行上述序列，
i将递增两个）这并不是完全不可想象的未来的处理器可能会提供类似的功能。如果编译器按照上面的指示编写
i++（在标准下合法）并且在整个表达式的求值过程中散布上述指令（也是合法的），并且如果它没有发生请注意，其他指令之一碰巧访问了 i，编译器有可能（并且合法）生成一系列会导致死锁的指令。可以肯定的是，在两个地方使用相同变量i的情况下，编译器几乎肯定会检测到问题，但如果例程接受对两个指针p的引用和q，并在上面的表达式中使用(*p)和(*q)（而不是使用i 两次）编译器不需要识别或避免如果p和q都传递了相同对象的地址。While it is unlikely that any compilers and processors would actually do so, it would be legal, under the C standard, for the compiler to implement "i++" with the sequence:
While I don't think any processors support the hardware to allow such a thing to be done efficiently, one can easily imagine situations where such behavior would make multi-threaded code easier (e.g. it would guarantee that if two threads try to perform the above sequence simultaneously,
iwould get incremented by two) and it's not totally inconceivable that some future processor might provide a feature something like that.If the compiler were to write
i++as indicated above (legal under the standard) and were to intersperse the above instructions throughout the evaluation of the overall expression (also legal), and if it didn't happen to notice that one of the other instructions happened to accessi, it would be possible (and legal) for the compiler to generate a sequence of instructions that would deadlock. To be sure, a compiler would almost certainly detect the problem in the case where the same variableiis used in both places, but if a routine accepts references to two pointerspandq, and uses(*p)and(*q)in the above expression (rather than usingitwice) the compiler would not be required to recognize or avoid the deadlock that would occur if the same object's address were passed for bothpandq.虽然
a = a++或a++ + a++等表达式的语法是合法的，但这些构造的行为是未定义，因为不遵守 C 标准中的应。 C99 6.5p2：使用 脚注 73 进一步澄清
各种序列点列于 C11 （和 C99):
C11 中同一段落的措辞是：
您可以通过使用最新版本的 GCC 来检测程序中的此类错误
-Wall和-Werror，然后 GCC 将彻底拒绝编译你的程序。以下是 gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005 的输出：重要的部分是了解 什么是序列点 - 以及什么是序列点以及不是。例如，逗号运算符是一个序列点，因此
定义良好，并且会将
i增加1，产生旧值，丢弃该值；然后在逗号运算符处解决副作用；然后将i加一，结果值就成为表达式的值 - 即，这只是编写j = (i += 2)的一种人为方式，其中又是一种“聪明”的书写方式。但是，函数参数列表中的
,不是逗号运算符，并且不同参数的计算之间没有序列点；相反，他们的评估彼此之间没有顺序；因此函数调用具有未定义的行为，因为函数参数中的
i++和++i的计算之间没有序列点< /strong>，因此i的值在上一个序列和下一个序列之间被i++和++i修改两次观点。While the syntax of the expressions like
a = a++ora++ + a++is legal, the behaviour of these constructs is undefined because a shall in C standard is not obeyed. C99 6.5p2:With footnote 73 further clarifying that
The various sequence points are listed in Annex C of C11 (and C99):
The wording of the same paragraph in C11 is:
You can detect such errors in a program by for example using a recent version of GCC with
-Walland-Werror, and then GCC will outright refuse to compile your program. The following is the output of gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005:The important part is to know what a sequence point is -- and what is a sequence point and what isn't. For example the comma operator is a sequence point, so
is well-defined, and will increment
iby one, yielding the old value, discard that value; then at comma operator, settle the side effects; and then incrementiby one, and the resulting value becomes the value of the expression - i.e. this is just a contrived way to writej = (i += 2)which is yet again a "clever" way to writeHowever, the
,in function argument lists is not a comma operator, and there is no sequence point between evaluations of distinct arguments; instead their evaluations are unsequenced with regard to each other; so the function callhas undefined behaviour because there is no sequence point between the evaluations of
i++and++iin function arguments, and the value ofiis therefore modified twice, by bothi++and++i, between the previous and the next sequence point.您的问题可能不是“为什么这些构造在 C 中是未定义的行为？”。您的问题可能是，“为什么这段代码（使用
++）没有给我预期的值？”，有人将您的问题标记为重复，并将您发送到这里。这个答案试图回答这个问题：为什么你的代码没有给你预期的答案，以及如何学习识别（并避免）无法按预期工作的表达式。
我假设您现在已经听说过 C 的
++和--运算符的基本定义，以及前缀形式++x的不同之处来自后缀形式x++。但这些运算符很难思考，因此为了确保您理解，也许您编写了一个包含类似内容的小测试程序但是，令您惊讶的是，这个程序并没有帮助您理解 - 它打印了一些奇怪的、无法解释的输出，表明也许
++做了一些完全不同的事情，根本不是你想象的那样。或者，也许您正在看到一个难以理解的表达式，例如“
也许有人给了您该代码作为谜题”。这段代码也没有任何意义，特别是如果你运行它 - 如果你在两个不同的编译器下编译和运行它，你可能会得到两个不同的答案！这是怎么回事？哪个答案是正确的？ （答案是它们都是，或者都不是。）
正如您现在所听到的，这些表达式是未定义，这意味着 C 语言不保证它们的含义会的。这是一个奇怪且令人不安的结果，因为您可能认为您可以编写的任何程序，只要编译并运行，都会生成唯一的、定义良好的输出。但在未定义行为的情况下，情况并非如此。
是什么导致表达式未定义？涉及
++和--的表达式总是未定义吗？当然不是：这些都是有用的运算符，如果正确使用它们，它们的定义是完美的。对于我们正在讨论的表达式，当同时发生太多事情时，当我们无法判断事情将以什么顺序发生时，但当顺序对我们得到的结果很重要时，使它们未定义的原因是。
让我们回到我在这个答案中使用的两个例子。当我写的
问题是，在实际调用
printf之前，编译器是否首先计算x的值，或者x++，或者可能++x？但事实证明我们不知道。 C 中没有规则规定函数的参数按从左到右、从右到左或其他顺序求值。所以我们不能说编译器是先执行x，然后是++x，然后是x++，还是x++ 然后++x然后x，或其他顺序。但顺序显然很重要，因为根据编译器使用的顺序，我们将清楚地打印出一系列不同的数字。这疯狂的表情是怎么回事？
该表达式的问题在于它包含三种不同的修改
x值的尝试： (1)x++部分尝试采用x的值，加1，将新值存储到x中，并返回旧值； (2)++x部分尝试获取x的值，加 1，将新值存储在x中，然后返回新价值； (3) x = 部分尝试将其他两个的总和赋回给 x。这三个尝试的任务中哪一个会“获胜”？这三个值中的哪一个将真正决定x的最终值？再次，也许令人惊讶的是，C 语言中没有任何规则可以告诉我们。您可能会认为优先级、关联性或从左到右的计算会告诉您事情发生的顺序，但事实并非如此。你可能不相信我，但请相信我的话，我再说一遍：优先级和结合性并不能决定 C 中表达式求值顺序的各个方面。特别是，如果在一个表达式内有多个当我们尝试为
x之类的东西分配新值的不同位置时，优先级和关联性并不能告诉我们哪些尝试首先发生，或者最后发生，或者其他什么。因此，在了解了所有背景和介绍之后，如果您想确保所有程序都定义良好，您可以编写哪些表达式，不能编写哪些表达式？
这些表达式都很好：
这些表达式都是未定义的：
最后一个问题是，如何判断哪些表达式是明确定义的，哪些表达式是未定义的？
正如我之前所说，未定义的表达式是那些同时发生太多事情的表达式，您无法确定事情发生的顺序，以及顺序很重要：
作为 #1 的示例，在表达式中
存在 3 次修改
x的尝试。作为 #2 的示例，在表达式中
我们都使用了 x 的值，并对其进行了修改。
这就是答案：确保在您编写的任何表达式中，每个变量最多被修改一次，并且如果修改了变量，您也不会尝试在其他地方使用该变量的值。
还有一件事。您可能想知道如何“修复”我在这个答案中提出的未定义表达式。
对于
printf("%d %d %d\n", x, ++x, x++);来说，很简单 - 只需将其写为三个单独的printf调用：现在行为已完全定义，您将得到合理的结果。
另一方面，对于 x = x++ + ++x 的情况，没有办法修复它。没有办法编写它来保证它的行为符合您的期望 - 但这没关系，因为无论如何您都不会在实际程序中编写像
x = x++ + ++x这样的表达式。Your question was probably not, "Why are these constructs undefined behavior in C?". Your question was probably, "Why did this code (using
++) not give me the value I expected?", and someone marked your question as a duplicate, and sent you here.This answer tries to answer that question: why did your code not give you the answer you expected, and how can you learn to recognize (and avoid) expressions that will not work as expected.
I assume you've heard the basic definition of C's
++and--operators by now, and how the prefix form++xdiffers from the postfix formx++. But these operators are hard to think about, so to make sure you understood, perhaps you wrote a tiny little test program involving something likeBut, to your surprise, this program did not help you understand — it printed some strange, inexplicable output, suggesting that maybe
++does something completely different, not at all what you thought it did.Or, perhaps you're looking at a hard-to-understand expression like
Perhaps someone gave you that code as a puzzle. This code also makes no sense, especially if you run it — and if you compile and run it under two different compilers, you're likely to get two different answers! What's up with that? Which answer is correct? (And the answer is that both of them are, or neither of them are.)
As you've heard by now, these expressions are undefined, which means that the C language makes no guarantee about what they'll do. This is a strange and unsettling result, because you probably thought that any program you could write, as long as it compiled and ran, would generate a unique, well-defined output. But in the case of undefined behavior, that's not so.
What makes an expression undefined? Are expressions involving
++and--always undefined? Of course not: these are useful operators, and if you use them properly, they're perfectly well-defined.For the expressions we're talking about, what makes them undefined is when there's too much going on at once, when we can't tell what order things will happen in, but when the order matters to the result we'll get.
Let's go back to the two examples I've used in this answer. When I wrote
the question is, before actually calling
printf, does the compiler compute the value ofxfirst, orx++, or maybe++x? But it turns out we don't know. There's no rule in C which says that the arguments to a function get evaluated left-to-right, or right-to-left, or in some other order. So we can't say whether the compiler will doxfirst, then++x, thenx++, orx++then++xthenx, or some other order. But the order clearly matters, because depending on which order the compiler uses, we'll clearly get a different series of numbers printed out.What about this crazy expression?
The problem with this expression is that it contains three different attempts to modify the value of
x: (1) thex++part tries to takex's value, add 1, store the new value inx, and return the old value; (2) the++xpart tries to takex's value, add 1, store the new value inx, and return the new value; and (3) thex =part tries to assign the sum of the other two back tox. Which of those three attempted assignments will "win"? Which of the three values will actually determine the final value ofx? Again, and perhaps surprisingly, there's no rule in C to tell us.You might imagine that precedence or associativity or left-to-right evaluation tells you what order things happen in, but they do not. You may not believe me, but please take my word for it, and I'll say it again: precedence and associativity do not determine every aspect of the evaluation order of an expression in C. In particular, if within one expression there are multiple different spots where we try to assign a new value to something like
x, precedence and associativity do not tell us which of those attempts happens first, or last, or anything.So with all that background and introduction out of the way, if you want to make sure that all your programs are well-defined, which expressions can you write, and which ones can you not write?
These expressions are all fine:
These expressions are all undefined:
And the last question is, how can you tell which expressions are well-defined, and which expressions are undefined?
As I said earlier, the undefined expressions are the ones where there's too much going at once, where you can't be sure what order things happen in, and where the order matters:
As an example of #1, in the expression
there are three attempts to modify
x.As an example of #2, in the expression
we both use the value of
x, and modify it.So that's the answer: make sure that in any expression you write, each variable is modified at most once, and if a variable is modified, you don't also attempt to use the value of that variable somewhere else.
One more thing. You might be wondering how to "fix" the undefined expressions I started this answer by presenting.
In the case of
printf("%d %d %d\n", x, ++x, x++);, it's easy — just write it as three separateprintfcalls:Now the behavior is perfectly well defined, and you'll get sensible results.
In the case of
x = x++ + ++x, on the other hand, there's no way to fix it. There's no way to write it so that it has guaranteed behavior matching your expectations — but that's okay, because you would never write an expression likex = x++ + ++xin a real program anyway.C 标准规定，一个变量最多只能在两个序列点之间分配一次。例如，分号是一个序列点。
因此，以下形式的每个语句：
等都违反了该规则。该标准还指出，行为是未定义的，而不是未指定的。一些编译器确实会检测到这些并产生一些结果，但这不符合标准。
但是，两个不同的变量可以在两个序列点之间递增。
以上是复制/分析字符串时的常见编码实践。
The C standard says that a variable should only be assigned at most once between two sequence points. A semi-colon for instance is a sequence point.
So every statement of the form:
and so on violate that rule. The standard also says that behavior is undefined and not unspecified. Some compilers do detect these and produce some result but this is not per standard.
However, two different variables can be incremented between two sequence points.
The above is a common coding practice while copying/analysing strings.
在 https://stackoverflow.com/questions/29505280/incrementing-array-index-in-c 有人询问这样的语句：
打印 7...OP 期望它打印 6。
++i增量不能保证在其余增量之前全部完成的计算。事实上，不同的编译器在这里会得到不同的结果。在您提供的示例中，执行前 2 个++i，然后读取k[]的值，然后读取最后一个++i> 然后k[]。现代编译器会对此进行很好的优化。事实上，可能比您最初编写的代码更好（假设它按照您希望的方式工作）。
In https://stackoverflow.com/questions/29505280/incrementing-array-index-in-c someone asked about a statement like:
which prints 7... the OP expected it to print 6.
The
++iincrements aren't guaranteed to all complete before the rest of the calculations. In fact, different compilers will get different results here. In the example you provided, the first 2++iexecuted, then the values ofk[]were read, then the last++ithenk[].Modern compilers will optimize this very well. In fact, possibly better than the code you originally wrote (assuming it had worked the way you had hoped).
文档 n1188 来自 ISO W14 站点。
我解释一下这些想法。
适用于这种情况的 ISO 9899 标准的主要规则是 6.5p2。
i=i++等表达式中的序列点位于i=之前和i++之后。在我上面引用的论文中，解释说您可以将程序理解为由小盒子组成，每个盒子包含两个连续序列点之间的指令。序列点在标准的附录 C 中定义，在 i=i++ 的情况下，有 2 个序列点界定完整表达式。这样的表达式在语法上与 Backus-Naur 语法形式中的
表达式语句条目等效（标准的附录 A 中提供了语法）。因此盒子内的说明顺序没有明确的顺序。
可以解释为
或 as
因为解释代码
i=i++的所有这些形式都是有效的，并且因为两者生成不同的答案，所以行为是未定义的。因此，可以通过组成程序的每个框的开头和结尾来看到序列点[这些框是C中的原子单元]，并且框内的指令顺序在所有情况下都没有定义。改变这个顺序有时会改变结果。
编辑：
解释此类歧义的其他好来源是来自 c-faq 网站（也发布了 作为一本书) ，即 此处 和此处 和此处 。
A good explanation about what happens in this kind of computation is provided in the document n1188 from the ISO W14 site.
I explain the ideas.
The main rule from the standard ISO 9899 that applies in this situation is 6.5p2.
The sequence points in an expression like
i=i++are beforei=and afteri++.In the paper that I quoted above it is explained that you can figure out the program as being formed by small boxes, each box containing the instructions between 2 consecutive sequence points. The sequence points are defined in annex C of the standard, in the case of
i=i++there are 2 sequence points that delimit a full-expression. Such an expression is syntactically equivalent with an entry ofexpression-statementin the Backus-Naur form of the grammar (a grammar is provided in annex A of the Standard).So the order of instructions inside a box has no clear order.
can be interpreted as
or as
because both all these forms to interpret the code
i=i++are valid and because both generate different answers, the behavior is undefined.So a sequence point can be seen by the beginning and the end of each box that composes the program [the boxes are atomic units in C] and inside a box the order of instructions is not defined in all cases. Changing that order one can change the result sometimes.
EDIT:
Other good source for explaining such ambiguities are the entries from c-faq site (also published as a book) , namely here and here and here .
原因是程序正在运行未定义的行为。问题在于求值顺序，因为根据 C++98 标准不需要序列点（根据 C++11 术语，没有操作在另一个操作之前或之后排序）。
但是，如果您坚持使用一种编译器，您会发现该行为是持久的，只要您不添加函数调用或指针，这会使行为更加混乱。
使用 Nuwen MinGW 15 GCC 7.1 您将得到：
GCC 是如何工作的？它按从左到右的顺序计算右侧 (RHS) 的子表达式，然后将值分配给左侧 (LHS) 。这正是 Java 和 C# 的行为方式和定义其标准的方式。 （是的，Java 和 C# 中的等效软件已定义行为）。它按照从左到右的顺序逐一评估 RHS 语句中的每个子表达式；对于每个子表达式：首先计算 ++c（前增量），然后使用值 c 进行操作，然后是后增量 c++）。
根据 GCC C++：运算符
按照 GCC 理解的定义行为 C++ 中的等效代码进行评估：
然后我们转到 Visual Studio 。 Visual Studio 2015，您会得到：
Visual Studio 是如何工作的，它采用另一种方法，它在第一遍中评估所有预增量表达式，然后在第二遍中的操作中使用变量值，在第三遍中从 RHS 分配到 LHS，然后最后一次，它一次性计算所有后增量表达式。
因此，Visual C++ 所理解的定义行为 C++ 中的等效项：
如 Visual Studio 文档所述 评估的优先级和顺序：
The reason is that the program is running undefined behavior. The problem lies in the evaluation order, because there is no sequence points required according to C++98 standard ( no operations is sequenced before or after another according to C++11 terminology).
However if you stick to one compiler, you will find the behavior persistent, as long as you don't add function calls or pointers, which would make the behavior more messy.
Using Nuwen MinGW 15 GCC 7.1 you will get:
How does GCC work? it evaluates sub expressions at a left to right order for the right hand side (RHS) , then assigns the value to the left hand side (LHS) . This is exactly how Java and C# behave and define their standards. (Yes, the equivalent software in Java and C# has defined behaviors). It evaluate each sub expression one by one in the RHS Statement in a left to right order; for each sub expression: the ++c (pre-increment) is evaluated first then the value c is used for the operation, then the post increment c++).
according to GCC C++: Operators
the equivalent code in defined behavior C++ as GCC understands:
Then we go to Visual Studio. Visual Studio 2015, you get:
How does Visual Studio work, it takes another approach, it evaluates all pre-increments expressions in first pass, then uses variables values in the operations in second pass, assign from RHS to LHS in third pass, then at last pass it evaluates all the post-increment expressions in one pass.
So the equivalent in defined behavior C++ as Visual C++ understands:
as Visual Studio documentation states at Precedence and Order of Evaluation:
理解这一点的关键是表达式
i++的值是i，它的作用是给i加1 code> （即，将值i+1存储在变量i中），但这并不意味着在确定值时就会进行存储。在像
i++ + ++i这样的表达式中，加法左侧的值为i，右侧为i+1。但是，当任何一方的效果发生时，它都是未定义的，因此整个表达式（
i++ + ++i）的值是未定义的。对i的第一次引用是否会使用当前语句之前的i值或右侧效果之后的值（未确认执行顺序），反之亦然对i的第二个引用是否会使用第一个引用效果后的值。 C 标准明确指出它是未定义的，定义它会将优化器限制为特定的执行顺序，这是没有帮助的。对于编译器来说，注意到最终效果是将
i增加 2 并求值（等于i+i+1及以后的值）是完全合理的（并且可能是有效的）将i+2存储在i中，或者不这样做，您不应该尝试找出编译器的功能并对其进行
更改 。设置，显然（对你来说！）与周围代码无关的更改或者新版本的编译器都可能会改变行为。
您可能会遇到一种最耗时的错误，这些错误会在明显未更改的代码中突然出现
（例如
2*i+1; 它对所有人类读者都有明显且有保证的含义。i+=2;）并意识到所有现代商业编译器（当优化开启时）都会将其转换为适合您的平台的最有效的代码，并且我什至建议 除了独立和之外，切勿在任何其他表达式中使用
++那只是因为它很容易阅读。不要以为它比i=i+1更高效，因为所有现代商业编译器都会为两者生成相同的代码。他们并不愚蠢。The key to understanding this is that the value of the expression
i++isiand it's effect is to add 1 toi(i.e. store the valuei+1in the variablei) but that does not mean that the store will take place when the value is determined.In an expression like
i++ + ++ithe value of the left-hand-side of the addition isiand right-hand-side isi+1.But it's undefined when the effect of either side takes place so undefined what the value of the whole expression (
i++ + ++i). Will the first reference toiuse the value ofibefore the current statement or the one after the effect of right hand side (no order of execution is confirmed) or vice versa will the second reference toiuse the value after the effect of the first one. The C Standard specifically states that is undefined and defining it constrains the optimiser to a specific order of execution which is unhelpful.It's perfectly reasonable (and possibly efficient) for a compilter to notice that the net effect is to increment
iby 2 and evaluate (what amounts toi+i+1and later storei+2ini, or not do that.What you should not do is try and work out what your compiler does and play to it.
Changes to the compiler optimisation settings, apparently (to you!) unrelated changes to the surrounding code or new releases of the compiler could all change the behaviour.
You lay yourself open to one of the most time consuming kinds of bug that suddenly arise in apparently unchanged code.
Write the code you need (e.g.
2*i+1; i+=2;) and realise that all modern commercial compilers will (when optimisation is on) translate that into the most efficient code for your platform and that it has an obvious and guaranteed meaning to all human readers.I even suggest never using
++in any other expression than standalone and then only because it's easy to read. Don't imagine it's somehow more efficient thani=i+1because all modern commercial compilers will emit the same code for both. They ain't daft.