post and pre increment

[jyots]

what is difference between
1. y=++x++;
2. y=(++x)++;
3. y=++(x++);

[JosAH]

what is difference between
1. y=++x++;
2. y=(++x)++;
3. y=++(x++);

Have you tried to compile your examples? If so, you would've noticed that none of them compile. A ++ operator (pre- and post) takes an lvalue as its operand and its result is an rvalue so you can't apply two of them in a row.

kind regards,

Jos

[jyots]

y=(++x)++;

this statement is givin no problem... but rest of them are givin error..

[JosAH]

y=(++x)++;

this statement is givin no problem... but rest of them are givin error..

That expression shouldn't compile either; if your compiler accepts it throw your compiler away and install a decent one. This is what the Standard has to say about it:

[#2] Except when it is the operand of the sizeof operator,
the unary & operator, the ++ operator, the -- operator, or
the left operand of the . operator or an assignment
operator, an lvalue that does not have array type is
converted to the value stored in the designated object (and
is no longer an lvalue). If the lvalue has qualified type,
the value has the unqualified version of the type of the
lvalue; otherwise, the value has the type of the lvalue. If
the lvalue has an incomplete type and does not have array

kind regards,

Jos

[YarrOfDoom]

Same here on bcc32, got any suggestions on another (freeware) compiler to use?

[goelvivek]

Download codeblocks it is free and update IDE and also come with mingw compiler

[YarrOfDoom]

Tried it, with the same results. Are you sure about this Jos, because now you've already declared 2 quite well known compilers (as far as I know anything about it) to be not good.

[weaknessforcats]

This code:

y=++x++;       //ERROR
y=(++x)++;     //OK
y=++(x++);     //ERROR

The postfix increment has a higher precedence so it goes first. The result of an x++ is not an l_value. That means you can't use it implicitly as an assignment. For that reason this code is also no good:

x++ = y;   //ERROR.

However, y= y=(++x)++ is OK because the result of ++x is an l_value:

++x = y;  //OK.

The reason for the difference is that the prefix operator actually changes the object whereas the postfix operator changes only a copy and that copy is not to be used as an l_value.

If your compiler rejects three of the examples, get a new compiler. Only the second example should compile.

[Tassos Souris]

This code:

y=++x++;       //ERROR
y=(++x)++;     //OK
y=++(x++);     //ERROR

The postfix increment has a higher precedence so it goes first. The result of an x++ is not an l_value. That means you can't use it implicitly as an assignment. For that reason this code is also no good:

x++ = y;   //ERROR.

However, y= y=(++x)++ is OK because the result of ++x is an l_value:

++x = y;  //OK.

The reason for the difference is that the prefix operator actually changes the object whereas the postfix operator changes only a copy and that copy is not to be used as an l_value.

If your compiler rejects three of the examples, get a new compiler. Only the second example should compile.

No this is not correct:

++x = y;

• The result of a prefix incrementation operator is not an lvalue.
• Postfix incrementation does not affect a copy of the operand but the operand itself. The difference, from the prefix incrementation, is the timing that the value is noted. As far as postfix incrementation is concerned, the value gets noted first and then the operand is incremented (++) or decremented (--) by 1.

[YarrOfDoom]

No this is not correct:

++x = y;

It compiles without a problem though.
But if you try:

int x = 0;
int y = 0;
++x = x;
++y = y+5;
cout << x << " " << y;

Output when compiled with bcc32: 1 5
Output when compiled with mingw: 1 6
So which one is right, or is neither of them?

[Tassos Souris]

Neither of them is correct. As Jos said the result is not a lvalue.
Visual Studio gives (correctly) a compile error:

error C2106: '=' : left operand must be l-value

For example, consider this:

int x[ 2 ];
int *ptr = x;

This is not correct:

++*ptr = 0;

That is, because the 'result' of the assignment expression depends on the ++ operator. The zero (0) will be placed after the ++ has been 'resolved'. Of course, ++ does not produce a lvalue so a compile time error must be given by the compiler.

However, these are correct

*++ptr = 0;
*ptr++ = 0;

Because the 'result' of the assignment "does not depend" on the ++ operator.
Let's examine the first case:

*++ptr = 0;

... the ++ does not produce a lvalue but then the * operator takes effect so everything is ok

*ptr++ = 0;

... the value is noted first, * takes place and then the ++ is activated (which has no effect on the assignment).

So the problem is not where the ++ or -- are: on the left or on the right of the = operator. But, if the result that they do not produce a lvalue actually affects the assignment.

[newb16]

Neither of them is correct. As Jos said the result is not a lvalue.

Jos said "...Except when it is the operand of the sizeof operator,
the unary & operator, the ++ operator..."

And i can quote(retype, as it's secured) 5.3.2.1 of the 14822 standard, regarding prefix ++/-- operator:
"The value is the new value of the operand; it is an lvalue"
You can

 printf("%p\n", &a );
 printf("%p\n", &++a );

And it should print the same.

[Tassos Souris]

Jos said "...Except when it is the operand of the sizeof operator,
the unary & operator, the ++ operator..."

And i can quote(retype, as it's secured) 5.3.2.1 of the 14822 standard, regarding prefix ++/-- operator:
"The value is the new value of the operand; it is an lvalue"
You can

 printf("%p\n", &a );
 printf("%p\n", &++a );

And it should print the same.

&++a

correct result:

'&' requires l-value

++ on a does not produce a lvalue so the use of &++a is illegal.

And this is of course logical. What does ++a do? It increments 'a' and returns back the new value.. why do you want to get the address of that new value?? this is both illegal and not logical...

And is exactly what Jos stated...
Common English indicate that the expression Except when means 'every other case except this'. When used other than as a operand to the sizeof() operator (that means in all cases; including our examples) it does not produce an lvalue.

This is legal:

int y = 0;
size_t size = sizeof( ++y );

, and also, since the operand of the sizeof() operator is not evaluated if it is not a variable length array type, y remains 0.

[newb16]

&++a

correct result:

'&' requires l-value

++ on a does not produce a lvalue so the use of &++a is illegal.

Compiler version, please. If it works contrary to what 5.3.2.1 of the 14822 standard says regarding prefix ++/-- operator:
"The value is the new value of the operand; it is an lvalue"

It works on old dos turbo c and on gcc 3.3.3 from cygwin.

And this is of course logical. What does ++a do? It increments 'a' and returns back the new value.. why do you want to get the address of that new value?? this is both illegal and not logical...

Not only new value, but the variable itself that holds the new value. This is not the case of postfix one, when the old value is returned and the variable itself holds the new value.

[newb16]

++y = y+5;
So which one is right, or is neither of them?

The result of this expression is undefined, because compiler can add 5 to old value, increment y in left part, and then overwrite it with 5, or increment first and then calculate 1+5 and then assign; It happns because the only 'sequence point' here is at the end of the expression.