By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,261 Online
Bytes IT Community
+ Ask a Question
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
Share this Question
Share on Google+
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"
<di**********@gmail.comwrote in comp.lang.c++:
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. You wrote a statement that modifies
the value of an object twice, and additionally reads the value another
time not involved in the calculation of the new value. All without
any sequence points in between.

The behavior is undefined, and the C++ standard does not specify or
care what happens.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jun 15 '07 #4

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 100
98

could 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 <john_androni...@hotmail.com>
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 <john_androni...@hotmail.com>
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.
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 <john_androni...@hotmail.comwrote:
James Kanze wrote:
On Jun 17, 10:17 am, John Harrison <john_androni...@hotmail.com>
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.