1

Just explain why this happens in 2nd line :

int i=5; 
printf(" Before %d then operated %d and after %d", i, ++i, i); // Before 6 then operated 6 and after 5
printf("\n And now %d", i); //And now 6

As far what I've learned, the result should be before 5 then operated 6 and after 6. I couldn't get explain from whom i am learning.. I'm a newbie to C

tested in Borland C++ 5 and codeblocks...

tshepang
  • 12,111
  • 21
  • 91
  • 136
Monolord's Knight
  • 163
  • 1
  • 12
  • possible duplicate of [Why are these constructs undefined behavior?](http://stackoverflow.com/questions/949433/why-are-these-constructs-undefined-behavior) – haccks Jan 15 '14 at 17:35
  • @haack this is decidedly NOT a duplicate of that post. OP does not modify the same variable within a single sequence point. – Andrey Mishchenko Jan 15 '14 at 17:36
  • 1
    @haccks could find a way to search this question anybody posted before as i don't know how to describe it unless showing... thanks – Monolord's Knight Jan 15 '14 at 17:37
  • @Andrey; What? Op is doing same. The `,` inside the `printf` is not a comma operator. – haccks Jan 15 '14 at 17:39
  • @haccks the important point in the question you link to is that the asker has multiple modifications of a given variable within a single expression. OP only ever modifies `i` once, after initialization. – Andrey Mishchenko Jan 15 '14 at 17:41
  • 1
    @Andrey; Although modification is only once, the behavior is undefined. And why behavior is undefined when modifying a variable more than once between two sequence points? The answer lies in the *order of evaluation of the sub-expressions*. Same reason is valid in this case. Take a look at [this](http://www.c-faq.com/expr/evalorder1.html) and [this](http://www.c-faq.com/expr/seqpoints.html). See the resoning of the undefined behavior. – haccks Jan 15 '14 at 17:47

2 Answers2

4

The evaluation order of function parameters is unspecified, and is determined by the argument type, the called function's calling convention, the optimization, the architecture and the compiler.

From c99 standard:

6.5.2.2 Function calls

The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call.

Just to add some experiences (borrowed from here).
The following code:

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

results in

2 1 3 - using g++ 4.2.1 on Linux.i686
1 2 3 - using SunStudio C++ 5.9 on Linux.i686
2 1 3 - using g++ 4.2.1 on SunOS.x86pc
1 2 3 - using SunStudio C++ 5.9 on SunOS.x86pc
1 2 3 - using g++ 4.2.1 on SunOS.sun4u
1 2 3 - using SunStudio C++ 5.9 on SunOS.sun4u

Community
  • 1
  • 1
herohuyongtao
  • 49,413
  • 29
  • 133
  • 174
  • 1
    It could also depend on optimizations. – Shafik Yaghmour Jan 15 '14 at 17:53
  • 1
    Trying to say what the order is determined by doesn't really help. A compiler writer is justified in choosing *any order* for *any reason whatsoever*. A compiler writer can decide that the order is based on the phase of the moon if they want. The important point is that the order is not known and therefore you should not write code that relies upon you knowing it. – Eric Lippert Jan 15 '14 at 19:03
1

You probably think that the evaluation order in printf is from left to right. This is wrong!

The evaluation order of function parameters is unspecified.

In your particular example it seems that the order is from right to left.

laaposto
  • 11,835
  • 15
  • 54
  • 71