can you explain this

int i=10;
printf("%d\n",++i);
i=10;
printf("%d%d\n",++i, i++);
i=10;
printf("%d%d%d\n",++i, i++, ++i);

11 -----------------ok
1210 ------------------------ is that evaluating from right to left ?
131113 ----- what the ...





can someone explain the 3rd print

Before you attempt to determine what is happening, you should keep in mind that the C standard allows for syntactically correct expressions that result in undefined behaviour. For example, you might consider:

Quote:

---

Originally Posted by C11 Clause 6.5 Paragraphs 2-3

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.

The grouping of operators and operands is indicated by the syntax. Except as specified later, side effects and value computations of subexpressions are unsequenced.

---

Quote:

---

Originally Posted by C11 Clause 6.5.2.2 Paragraph 10

There is a sequence point after the evaluations of the function designator and the actual arguments but before the actual call. Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.

---

The second quote basically implies that the evaluations of function actual arguments is unsequenced relative to each other, i.e., the compiler might choose right to left evaluation, or left to right, or some random order that is inconsistent between compilations, and all is well by the standard. This clearly can apply here, so with this we already know that at the very least if we wanted to explain, we could very well explain it as "because the compiler decided to do that".

However, because side effects unsequenced relative to each other are involved, the first quote also applies here. As a result you're observing the effects of undefined behaviour, i.e., not only is the compiler permitted to order the evaluation as it pleases, it could do pretty much anything else within its purview, perhaps causing "Hello world!" to be printed.

so all of that you are saying is "that depends on the compiler"

Yes, but you should keep in mind that while some things that are left to the compiler are merely differences in implementation that you might want to take note, maybe avoid, where undefined behaviour is concerned, it means that your code is semantically wrong even though it is syntactically correct.

There are 4 levels of fidelity within C.

Defined behaviour - the standard specifies exactly what happens, and every compiler has to do it that way.

Implementation specific behaviour - the standard specifies a small set of options, and the compiler picks one. An example is whether 'char' is signed or unsigned by default.

Unspecified behaviour - For example, given a = f(b) + g(b);, it is unspecified whether f() or g() is called first. So long as there are no interdependent side effects with f() and g(), the overall result is consistent regardless of the calling order.

Undefined behaviour - Basically, you're on your own. One vital concept you need to understand is the concept of a sequence point, and the "modified once" rule. These are explained in the links below.

Read these as well -> Expressions and comp.lang.c Frequently Asked Questions

Additionally, implementation defined and unspecified behavior may seem similar, but there's a key difference. With implementation defined behavior, the compiler must document its choice. With unspecified behavior, no such documentation is required.