pre/post increment blues

[divya_rathore_]

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?

 

[Gianni Mariani]

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.

 

[Robert Bauck Hamar]

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-lite/misc-technical-issues.html#faq-39.15

 

[Jack Klein]

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

 

[John Harrison]

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

 

[Michael DOUBEZ]

Gianni Mariani a écrit :

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

 

[divya_rathore_]

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).

 

[John Harrison]

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

 

[John Harrison]

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

 

[James Kanze]

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.

 

[John Harrison]

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

 

[James Kanze]

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.