Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Maybe easy wording could be easier for understanding than the rigorous definition of the standards.</p> <p><strong>implementation-defined behavior</strong><br> The language says that we have data-types. The compiler vendors specify what sizes shall they use, and provide a documentation of what they did.</p> <p><strong>undefined behavior</strong><br> You are doing something wrong. For example, you have a very large value in an <code>int</code> that doesn't fit in <code>char</code>. How do you put that value in <code>char</code>? actually there is no way! Anything could happen, but the most sensible thing would be to take the first byte of that int and put it in <code>char</code>. It is just wrong to do that to assign the first byte, but thats what happens under the hood.</p> <p><strong>unspecified behavior</strong><br> Which function of these two is executed first?</p> <pre><code>void fun(int n, int m); int fun1() { cout &lt;&lt; "fun1"; return 1; } int fun2() { cout &lt;&lt; "fun2"; return 2; } ... fun(fun1(), fun2()); // which one is executed first? </code></pre> <p>The language doesn't specify the evaluation, left to right or right to left! So an unspecified behavior may or mayn't result in an undefined behavior, but certainly your program should not produce an unspecified behavior.</p> <hr> <p>@eSKay I think your question is worth editing the answer to clarify more :)</p> <blockquote> <p>for <code>fun(fun1(), fun2());</code> isn't the behaviour "implementation defined"? The compiler has to choose one or the other course, after all?</p> </blockquote> <p>The difference between implementation-defined and unspecified, is that the compiler is supposed to pick a behavior in the first case but it doesn't have to in the second case. For example, an implementation must have one and only one definition of <code>sizeof(int)</code>. So, it can't say that <code>sizeof(int)</code> is 4 for some portion of the program and 8 for others. Unlike unspecified behavior, where the compiler can say OK I am gonna evaluate these arguments left-to-right and the next function's arguments are evaluated right-to-left. It can happen in the same program, that's why it is called <strong><em>unspecified</em></strong>. In fact, C++ could have been made easier if some of the unspecified behaviors were specified. Take a look here at <a href="http://www2.research.att.com/~bs/bs_faq2.html#undefined" rel="noreferrer">Dr. Stroustrup's answer for that</a>:</p> <blockquote> <p>It is claimed that the difference between what can be produced giving the compiler this freedom and requiring "ordinary left-to-right evaluation" can be significant. I'm unconvinced, but with innumerable compilers "out there" taking advantage of the freedom and some people passionately defending that freedom, a change would be difficult and could take decades to penetrate to the distant corners of the C and C++ worlds. I am disappointed that not all compilers warn against code such as ++i+i++. Similarly, the order of evaluation of arguments is unspecified.</p> <p>IMO far too many "things" are left undefined, unspecified, implementation-defined, etc. However, that's easy to say and even to give examples of, but hard to fix. It should also be noted that it is not all that difficult to avoid most of the problems and produce portable code.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload