blocks|key|3204002|text|回答您的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204003|我认为“未定义的行为”意味着编译器/语言实现者可以自由地做它认为最好的任何事情，而不是它可能导致多个未指定的行为它不是未指定的行为(+result.|3204004|Because+)。它的行为是undefined.|unordered-list-item|offset|length|style|BOLD|3204005|
，这显然是指定的|3204006|entityMap^0|0|0|F|9|0|6|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@$G|R|H|S|I|J]]|9|@]|A|$]]|$1|K|3|L|5|6|7|T|8|@$G|U|H|V|I|J]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|N|$]]

To answer your questions:

<ol>
<li>I think "undefined behavior" means that the compiler/language implementator is free to do whatever it thinks best, and no that it could lead to more than one result.</li>
<li>Because it's not unspecified. It's clearly specified that its behavior is undefined.</li>
</ol>

blocks|key|283968|text|这句话，"…i的最终值将是4，不管…的顺序如何“是不正确的。编译器可能会发出与以下内容等效的代码：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|283969|i+=+3;
int+tmp+=+i;
%2B%2Bi;
i+=+tmp;|code-block|syntax|javascript|283970|或者这样：|283971|i+=+3;
%2B%2Bi;
i+=+i+-+1;|283972|283973|i+=+3;
i+=+i;
%2B%2Bi;|283974|至于术语的定义，如果答案保证是4，那就不是未指定或未定义的行为，它将是已定义的行为。|283975|根据标准(Wikipedia)，它是未定义的行为，所以它甚至可以自由地这样做：|283976|i+=+3;
system("sudo+rm+-rf+/");+//+DO+NOT+TRY+THIS+AT+HOME+…+OR+AT+WORK+…+OR+ANYWHERE.|283977|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Undefined_behavior^0|6|1|0|0|0|0|0|0|0|5|9|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|18|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|19|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|1A|8|@]|D|@]|E|$I|J]]|$1|O|3|L|5|6|7|1B|8|@]|D|@]|E|$]]|$1|P|3|Q|5|H|7|1C|8|@]|D|@]|E|$I|J]]|$1|R|3|S|5|6|7|1D|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1E|8|@]|D|@$9|1F|A|1G|1|1H]]|E|$]]|$1|V|3|W|5|H|7|1I|8|@]|D|@]|E|$I|J]]|$1|X|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]]|Y|$Z|$5|10|11|12|E|$13|14]]]]

The phrase, "…the final value of <code>i</code> will be 4 no matter what the order of evaluation…" is incorrect. The compiler could emit the equivalent of this:

<pre><code>i = 3;
int tmp = i;
++i;
i = tmp;
</code></pre>

or this:

<pre><code>i = 3;
++i;
i = i - 1;
</code></pre>

or this:

<pre><code>i = 3;
i = i;
++i;
</code></pre>

As to the definitions of terms, if the answer was guaranteed to be 4, that wouldn't be unspecified or undefined behavior, it would be defined behavior.

As it stands, it is undefined behaviour according to the standard (<a href="http://en.wikipedia.org/wiki/Undefined_behavior" rel="noreferrer">Wikipedia</a>), so it's even free to do this:

<pre><code>i = 3;
system("sudo rm -rf /"); // DO NOT TRY THIS AT HOME … OR AT WORK … OR ANYWHERE.
</code></pre>

blocks|key|3204094|text|i=和i%2B%2B都是修改i的副作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204095|i%2B%2B并不意味着i仅在整个语句求值后递增，而只是表示i的当前值已被读取。因此，赋值和递增可以以任何顺序发生。|3204096|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

i=, and i++ are both side effects that modify i.

i++ does not imply that i is only incremented after the entire statement is evaluated, merely that the current value of i has been read.
As such, the assignment, and the increment, could happen in any order.

blocks|key|3204129|text|当您可以简单地输入i=i%2B%2B时，输入i%2B%2B是不值得的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204130|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's not worth it to type i=i++ when you could simply type i++.

blocks|key|282037|text|在C和C%2B%2B中，两个sequence+points之间的任何操作的顺序完全由编译器决定，不能依赖于。该标准定义了一个组成序列点的列表，从内存中看，这是|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|282038|在调用函数之前，语句后面的分号和所有函数参数的逗号与%7C%7C+|282039|%7C%7C|ordered-list-item|282040|282041|282042|282043|查看维基百科上的页面，这些列表更完整，描述也更详细。序列点是一个非常重要的概念，如果您还不知道它的含义，那么立即学习它将使您受益良多。|282044|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Sequence_point^0|A|F|0|0|0|1|1|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|10|8|@]|9|@]|C|$]]|$1|I|3|-4|5|H|7|11|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|12|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

In C and also in C++, the order of any operation between two <a href="http://en.wikipedia.org/wiki/Sequence_point" rel="nofollow">sequence points</a> is completely up to the compiler and cannot be dependent on. The standard defines a list of things that makes up sequence points, from memory this is

<ol>
<li>the semicolon after a statement</li>
<li>the comma operator</li>
<li>evaluation of all function arguments before the call to the function</li>
<li>the &amp;&amp; and || operand</li>
</ol>

Looking up the page on wikipedia, the lists is more complete and describes more in detail. Sequence points is an extremely important concept and if you do not already know what it means, you will benefit greatly by learning it right away.

blocks|key|3204186|text|不，我们不使用术语“未定义的行为”，当它可以简单地导致一个以上的算术结果。当行为被限制为不同的算术结果(或者，更一般地，一些可预测的结果集)时，它通常被称为未指定的行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3204187|未定义的行为意味着完全不可预测和无限的后果，如格式化计算机上的硬盘驱动器或简单地使您的程序崩溃。i+=+i%2B%2B是一种未定义的行为。|offset|length|style|CODE|3204188|在这种情况下，i应该是4的想法是从哪里得到的还不清楚。在C%2B%2B语言中，绝对没有任何东西可以让您得出这样的结论。|3204189|entityMap^0|0|1C|7|0|7|1|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@$D|Q|E|R|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

No, we don't use the term "undefined behavior" when it can simply lead to more than one arithmetical result. When the behavior is limited to different arithmetical results (or, more generally, to some set of predictable results), it is typically referred to as unspecified behavior. 

Undefined behavior means completely unpredictable and unlimited consequences, like formatting the hard drive on your computer or simply making your program to crash. And <code>i = i++</code> is undefined behavior.

Where you got the idea that <code>i</code> should be 4 in this case is not clear. There's absolutely nothing in C++ language that would let you come to that conclusion.

blocks|key|278541|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|278542|否，根据评估顺序的不同，结果会有所不同。增量和赋值之间没有计算边界，因此可以在赋值之前或之后执行增量。考虑一下这个行为：|ordered-list-item|278543|278544|load+i+into+CX
copy+CX+to+DX
increase+DX
store+DX+in+i
store+CX+in+i|code-block|syntax|javascript|278545|结果是i包含3，而不是4。|offset|length|style|CODE|278546|作为比较，在C#中，表达式的求值和赋值之间存在求值边界，因此结果始终为3。|278547|278548|即使没有指定确切的行为，该规范也非常清楚地说明了它涵盖了什么和没有涵盖什么。行为被指定为未定义，它不是unspecified.|278549|278550|entityMap^0|0|0|0|0|3|1|6|1|B|1|0|Z|1|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Y|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|E|3|F|4|G|6|10|7|@]|8|@]|9|$H|I]]|$1|J|3|K|4|5|6|11|7|@$L|12|M|13|N|O]|$L|14|M|15|N|O]|$L|16|M|17|N|O]]|8|@]|9|$]]|$1|P|3|Q|4|5|6|18|7|@$L|19|M|1A|N|O]]|8|@]|9|$]]|$1|R|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|S|3|T|4|C|6|1C|7|@]|8|@]|9|$]]|$1|U|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]]|W|$]]

1.
No, the result will be different depending on the order of evaluation. There is no evaluation boundary between the increment and the assignment, so the increment can be performed before or after the assignment. Consider this behaviour:

<pre><code>load i into CX
copy CX to DX
increase DX
store DX in i
store CX in i
</code></pre>

The result is that <code>i</code> contains <code>3</code>, not <code>4</code>.

As a comparison, in C# there is a evaluation boundary between the evaulation of the expression and the assignment, so the result will always be <code>3</code>.

2.
Even if the exact behaviour isn't specified, the specification is very clear on what it covers and what it doesn't cover. The behaviour is specified as undefined, it's not unspecified.

blocks|key|2990593|text|我在OCAJP练习考试中看到过这样的问题。IntelliJ的IDEA反编译器将这个|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2990594|public+static+int+iplus(){
++++int+i=0;
++++return+i=i%2B%2B;
}|code-block|syntax|javascript|2990595|进入到这个|2990596|public+static+int+iplus()+{
++++int+i+=+0;
++++byte+var10000+=+i;
++++int+var1+=+i+%2B+1;
++++return+var10000;
}|2990597|从模块创建JAR，然后导入为库并检查。|2990598|📷|atomic|offset|length|2990599|​|2990600|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/5f2830f67c961158ebcd08684aeed39d.png|imageAlt^0|0|0|0|0|0|0|1|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|17|8|@]|9|@$P|18|Q|19|1|1A]]|A|$]]|$1|R|3|S|5|6|7|1B|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10|11|-4]]]]

I saw such question at OCAJP practice test.
IntelliJ's IDEA decompiler turns this

<pre><code>public static int iplus(){
 int i=0;
 return i=i++;
}
</code></pre>

into this

<pre><code>public static int iplus() {
 int i = 0;
 byte var10000 = i;
 int var1 = i + 1;
 return var10000;
}
</code></pre>

Create JAR from module, then import as library &amp; inspect.
<a href="https://i.stack.imgur.com/7IKex.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/7IKex.png" alt="enter image description here"></a>

blocks|key|284136|text|这个问题很老了，但似乎仍然经常被引用，所以根据C%2B%2B17对标准的更改，它应该有一个新的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|284137|expr.ass第1款解释|offset|length|284138|284139|+...赋值是在右操作数和左操作数的值计算之后排序的…|blockquote|284140|284141|284142|和|284143|284144|右操作数排序在左操作数之前。|284145|284146|284147|这里的含义是右操作数的副作用在赋值之前排序，这意味着basic.exec中的规定不会处理表达式|284148|284149|如果内存位置上的副作用(intro.memory)相对于同一内存位置上的另一副作用或使用同一内存位置中的任何对象的值进行的值计算未排序，并且它们不可能并发(intro.multithread)，则该行为是未定义的|284150|284151|284152|行为已定义，如紧随其后的示例所述。|284153|另请参阅：What+made+i+=+i%2B%2B+%2B+1;+legal+in+C%2B%2B17?|284154|entityMap|0|LINK|mutability|MUTABLE|url|http://eel.is/c%2B%2Bdraft/expr.ass|1|http://eel.is/c%2B%2Bdraft/basic.exec|2|https://stackoverflow.com/questions/47702220/what-made-i-i-1-legal-in-c17^0|0|0|8|0|0|0|0|0|0|0|0|0|0|0|Q|A|1|0|0|0|0|0|0|5|12|2|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@]|9|@$D|1H|E|1I|1|1J]]|A|$]]|$1|F|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|1L|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1O|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|O|3|P|5|I|7|1Q|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1T|8|@]|9|@$D|1U|E|1V|1|1W]]|A|$]]|$1|U|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|V|3|W|5|I|7|1Y|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|20|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|21|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|22|8|@]|9|@$D|23|E|24|1|25]]|A|$]]|$1|13|3|-4|5|6|7|26|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A]]|1B|$5|16|17|18|A|$19|1C]]|1D|$5|16|17|18|A|$19|1E]]]]

This question is old, but still appears to be referenced frequently, so it deserves a new answer in light of changes to the standard, from C++17.

<a href="http://eel.is/c++draft/expr.ass" rel="nofollow noreferrer">expr.ass</a> Subclause 1 explains 

<blockquote>
 ... the assignment is sequenced after the value computation of the right and left operands ...
</blockquote>

and

<blockquote>
 The right operand is sequenced before the left operand.
</blockquote>

The implication here is that the side-effects of the right operand are sequenced before the assignment, which means that the expression is not addressed by the provision in [basic.exec] <a href="http://eel.is/c++draft/basic.exec" rel="nofollow noreferrer">Subclause 10</a>:

<blockquote>
 If a side effect on a memory location ([intro.memory]) is unsequenced relative to either another side effect on the same memory location or a value computation using the value of any object in the same memory location, and they are not potentially concurrent ([intro.multithread]), the behavior is undefined
</blockquote>

The behavior is defined, as explained in the example which immediately follows.

See also: <a href="https://stackoverflow.com/questions/47702220/what-made-i-i-1-legal-in-c17">What made i = i++ + 1; legal in C++17?</a>

<blockquote>
 Possible Duplicate: 
 <a href="https://stackoverflow.com/questions/949433/could-anyone-explain-these-undefined-behaviors-i-i-i-i-i-etc">Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc&hellip;)</a> 
</blockquote>



According to c++ standard,

<pre><code>i = 3;
i = i++;
</code></pre>

will result in undefined behavior.

We use the term "undefined behavior" if it can lead to more then one result. But here, the final value of <code>i</code> will be 4 no matter what the order of evaluation, so shouldn't this really be called "unspecified behavior"?

Is the behaviour of i = i++ really undefined?

编译器

 可能重复：根据c++标准，i = 3;i = i++;将导致未定义的行为。我们使用术语“未定义的行为”，如果它可以导致不止一个结果。但在这里，无论计算顺序如何，i的最终值都将是4，所以这不应该被称为“未指定的行为”吗？

问I= i++的行为真的是未定义的吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问I= i++的行为真的是未定义的吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问I= i++的行为真的是未定义的吗？
EN