increment operators

[aslan93]

int a, c=11;
a =c++ + ++c + ++c;

the value of 'a' comes out to be 37.

can someone please explain me how is the value of 'a' computed in the above case?
what is the general preference order of operations?

i know that the associativity order is from right to left. but is there any order of preference between post-increment and pre-increment operator?

please reply.

[Moschops]

This is "undefined behaviour". It could do anything at all. Do not do this. The C++ standard explicitly states that when you mix increment operators like this, there's no way to know what will happen.

[oonej]

its not really undefined behaviour

in operator precedence, it works left to right (excluding the = operator)

C++ + ++C first, but the first C++ doesnt increment till after the operation

thus 11 + 12 = 23

then c increments due to the post operator, making it 13, then the pre increment making it 14

then we have 23 + 14 = 37

[MrHutch]

Either way, if I saw somebody write something like that I'd be inclined to clip them around the ear....

[oonej]

@iHutch105

I agree completely, but on one of my exams in my c class, our teacher put crap like this on our exam. Thus we had to learn the precedence operations of such stupidity.

[Moschops]

its not really undefined behaviour

And yay, the holy book (2003 edition) did state, in Section 5 Paragraph 5:

"Between the previous and next sequence point a scalar object shall have its value modified at most once by the evaluation of an expression.... otherwise the behaviour is undefined."

Piecing together what this compiler chose to do in this situation does not change this.

[Caligulaminus]

oonej

It is undefined behaviour.
The standard explicitly states that the result of a statement that modifies a variable more than once is not defined.

[Gaminic]

@oonej:

its not really undefined behaviour

in operator precedence, it works left to right (excluding the = operator)

C++ + ++C first, but the first C++ doesnt increment till after the operation

thus 11 + 12 = 23

then c increments due to the post operator, making it 13, then the pre increment making it 14

then we have 23 + 14 = 37 

It doesn't make sense. Take c++ + ++c. You say the '++c' increments before the addition, but after c++ ('at pass'). To be consistent, c++ should have incremented after c++, but before ++c, making the total solution 11 + 13 + 14 = 38.

Now, c++ apparently incremented after the entire sum thing, mimicking this behaviour:

a = c + ++c + ++c;
c++;

To be consistent, ++c should have incremented before the start of the sum, to get this behaviour:

++c;
++c;
a = c + c + c;
c++;

In my eyes, this shows that whoever designed the compiler didn't account/care for mixed pre/post incrementing. Because he shouldn't have. Because it's undefined behaviour.

[viliml]

would ++a++ be OK?

[Gaminic]

That won't even compile. Not exactly sure why, though. I'm guessing ++a returns by value?

[aslan93]

thanks for the reply oonej...
ihutch..we had such questons in our previous college exams...so had to study...thanks for replying..

[oonej]

np,

as for everyone else, this is what i learned in my class... i assumed thats what he was going for too, i agree that this is unpredictable in a computer operation, but if you systematically go through and do the operations, it makes sense to me at least.. and i got a 100 on that exam, so i learned something...

i for one would never do an operation like this

[Moschops]

and i got a 100 on that exam, so i learned something...

There was a question like this on the exam and the correct answer answer for which marks were awarded wasn't "it's undefined"?

but if you systematically go through and do the operations, it makes sense to me at least

That's great for you, but you're not a C++ compiler conforming to the C++ standard, are you? Whatever "system" you mean when you say "systematically" is not C++.

[JLBorges]

> would ++a++ be OK?

>> That won't even compile. Not exactly sure why, though

The postfix increment operator has a higher precedence than the prefix increment operator.
So ++a++ is evaluated as ++( a++ )
Assuming that a standard type is involved, a++ results in an r-value; the prefix increment operator requires a modifiable l-value.

Note: (++a)++ would compile; the prefix increment operator which is evaluated first yields a modifiable l-value.

[Gaminic]

That makes sense. I hadn't taken into account precedence, and I figured '++a' would return an lvalue anyway. 'a++' obviously doesn't, of course.