424,963 Members | 1,261 Online
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

# pre/post increment blues

 P: n/a The code: int aaa = 100; printf("%d %d %d\n", --aaa, aaa, aaa--); printf("%d\n", aaa); prints: 99 100 100 98 could somebody explain the logic behind this? Jun 15 '07 #1
11 Replies

 P: n/a di************@gmail.com wrote: The code: int aaa = 100; printf("%d %d %d\n", --aaa, aaa, aaa--); printf("%d\n", aaa); prints: 99 100 100 98 could somebody explain the logic behind this? Yes. There is none. It's undefined behaviour. Jun 15 '07 #2

 P: n/a di************@gmail.com wrote: The code: int aaa = 100; printf("%d %d %d\n", --aaa, aaa, aaa--); printf("%d\n", aaa); prints: 99 100 100 98 could somebody explain the logic behind this? There is no logic behind this. It is undefined behaviour to modify a variable more than once in a statement. Read the warnings the compiler (presumably/hopefully) output. Anything could happen. Please read this: http://www.parashift.com/c++-faq-lit...html#faq-39.15 -- rbh Jun 15 '07 #3

 P: n/a On Thu, 14 Jun 2007 19:12:28 -0700, "di************@gmail.com"

 P: n/a di************@gmail.com wrote: The code: int aaa = 100; printf("%d %d %d\n", --aaa, aaa, aaa--); printf("%d\n", aaa); prints: 99 100 100 98 could somebody explain the logic behind this? It's undefined behaviour to modify a variable more than once without a sequence point inbetween (try googling for sequence point). So the compiler can do what it likes, there is no logic, you just broke the rules of C++. john Jun 15 '07 #5

 P: n/a Gianni Mariani a écrit : di************@gmail.com wrote: >The code: int aaa = 100; printf("%d %d %d\n", --aaa, aaa, aaa--); printf("%d\n", aaa);prints:99 100 10098could somebody explain the logic behind this? Yes. There is none. It's undefined behaviour. Compiler speaking: 1. This guy needs 3 values for his fonction lets do as less work as possible (in order to be quick of course) 2. lets set parameter 2: 'aaa', it is the easiest 3. lets set parameter 3:'aaa--', I already have the value, I can always decrement it in a future sequence point 4. lets decrement aaa and fill in parameter 1 5. next sequence point of function call, decrement aaa because of previous parameter 3 5. call function and ignore return value .... Of course another compiler may choose to do it differently provided the *defined behavior* is the same. Michael Jun 15 '07 #6

 P: n/a thanks everybody! I was wondering if the result is explainable in terms of operator precedence and pre/post incre/decre-ment. If a silly recruiter asks this as an interview question, he might expect a definite answer. No, I am treating this esteemed group for solving interview questions.. please don't take above statement in that perspective :) My intention is completely to address precedence and pre/post incre/ decre-ment in tricky situations (such as very well thought of interview questions to test specifics of a language). Jun 17 '07 #7

 P: n/a di************@gmail.com wrote: thanks everybody! I was wondering if the result is explainable in terms of operator precedence and pre/post incre/decre-ment. If a silly recruiter asks this as an interview question, he might expect a definite answer. No, I am treating this esteemed group for solving interview questions.. please don't take above statement in that perspective :) My intention is completely to address precedence and pre/post incre/ decre-ment in tricky situations (such as very well thought of interview questions to test specifics of a language). I don't think you 'got' the answers you were given. You example is NOT explainable in terms of the C++ language. It is UNDEFINED BEHAVIOUR as far as C++ goes. Of course th authors of which ever compiler you were using might have an explanation about why they made their compiler do that, but that is a question for the compiler writers, not a question for C++. And not a very interesting question either. If you want to pose question about operator precedence and pre and post increment you should stick to questions where the C++ language defines a particular behaviour. I only understood these issues when I realise that operators can have a value and a side effect. For ++x the value is x + 1, and the side effect is to increment x, for x++ the value is x, and the side effect is also to increment x. That's the only difference. Where newbies go wrong is that they think pre and post increment have something to do with the TIMING of when the increment operation happens, but they don't. Pre and post-increment operators are evaluated using exactly the same rules as any other operator, it is not the case that pre-increment happens 'first' and post-increment happens 'later' or any such thing. john Jun 17 '07 #8

 P: n/a Pre and post-increment operators are evaluated using exactly the same rules as any other operator, it is not the case that pre-increment happens 'first' and post-increment happens 'later' or any such thing. For instance newbies often think that in y = x++; that the increment happens after the assignment. But it doesn't, the rhs side of an assignment is always evaluated before the assignment happens, always. The truth is that the value of x++ is x, so x is the value that gets assigned to y. The side effect is to increment x, but that doesn't make any difference, the value of x++ is still x. john Jun 17 '07 #9

 P: n/a On Jun 17, 10:17 am, John Harrison wrote: Pre and post-increment operators are evaluated using exactly the same rules as any other operator, it is not the case that pre-increment happens 'first' and post-increment happens 'later' or any such thing. For instance newbies often think that in y = x++; that the increment happens after the assignment. But it doesn't, the rhs side of an assignment is always evaluated before the assignment happens, always. Which sounds, at least, as if you are saying that the incrementation happens before assignment. Your earlier statement was 100% correct. The expression has a value, and it has a side effect. The only guarantee concerning the side effect is that it will be visible before the next sequence point. -- James Kanze (Gabi Software) email: ja*********@gmail.com Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Jun 17 '07 #10

 P: n/a James Kanze wrote: On Jun 17, 10:17 am, John Harrison wrote: >>Pre andpost-increment operators are evaluated using exactly the same rules asany other operator, it is not the case that pre-increment happens'first' and post-increment happens 'later' or any such thing. >For instance newbies often think that in >y = x++; >that the increment happens after the assignment. But it doesn't, the rhsside of an assignment is always evaluated before the assignment happens,always. Which sounds, at least, as if you are saying that the incrementation happens before assignment. Your earlier statement was 100% correct. The expression has a value, and it has a side effect. The only guarantee concerning the side effect is that it will be visible before the next sequence point. In the case of built in types (which was the OP's original question) you're right. Thanks for the clarification. In the case of objects though, operator++ would always be called before operator=. There's no magic for post increment, just regular method calls. john Jun 17 '07 #11

 P: n/a On Jun 17, 3:27 pm, John Harrison Your earlier statement was 100% correct. The expression has a value, and it has a side effect. The only guarantee concerning the side effect is that it will be visible before the next sequence point. In the case of built in types (which was the OP's original question) you're right. Thanks for the clarification. In the case of objects though, operator++ would always be called before operator=. There's no magic for post increment, just regular method calls. Good point. User defined operators are in fact nothing but syntactic sugar. As far as the compiler is concerned, once the operator resolves to a user defined operator, it is just another function call. Both the call itself, and the return, represent sequence points, so any side effects resulting from expressions in the operator++ function will have occured before the result is available. -- James Kanze (Gabi Software) email: ja*********@gmail.com Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Jun 17 '07 #12

### This discussion thread is closed

Replies have been disabled for this discussion.