Found something odd with the increment operator. When incrementing after a
multiply by an odd literal number, it increments after the assignment. When
incrementing after a multiply after an even literal number, or after a
multiply by a variable with either an odd or even number, the final increment
is not performed.
Yes, I am aware the programming practice is poor in this case (both assignment
and increment of the same variable in the same statment). But shouldn't it be
consistent?
Example code follows:
// Dev-C++ ver 4.9.9.2#include<cstdlib>#include<iostream>usingnamespacestd;intmain(intargc,char*argv[]){intvalue;inta;a=2;value=2;value=2*value++;// literal evencout<<value<<endl;value=2;value=a*value++;// variable evencout<<value<<endl;cout<<endl;a=3;value=2;value=3*value++;// literal oddcout<<value<<endl;value=2;value=a*value++;// variable oddcout<<value<<endl;system("PAUSE");returnEXIT_SUCCESS;}/* output:4476Press any key to continue . . .*/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, when this code is executed in MSVC 2010 Express, the output is as
one would expect, the number 5 in the first two cases, and the number 7 in the
last two cases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ejohnson3
it is interesting.
Dev-C++'s compiler is based on GCC.
Lcc-Win32 and Pelle's-C are based on LCC.
It's clearly not a Dev-C++ bug as it extends beyond Dev-C++.
I don't think "post increment" trumps the assignment.
Logic would dictate that "value" would be incremented, "post assignment".
ie: a = 3, value = 2, value = (a * value), value++
at least, that's what VC is doing.
Lcc, Pelle, and DevC are failing to increment at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for trying some other compilers. DEV-C++ is incrementing in one special
case, the literal odd number. The other compliers (non VC) you reported on are
failing to increment in all four cases.
I find it strange that the compiler is sensitive in this way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ejohnson3
I experimented with "pre-increment" as well:
++value
and that didn't work either.
BTW, this forum gets very little attention these days, since Dev-C++ is no
longer maintained.
I seldom visit here, 2-3 times a month maybe. I would recommend the following
link:
Your example code exhibits undefined behavior - that's why various compilers
give various results - there's no such thing as a correct result.
value = 3 * value++;
You have the variable value modified more than once without an intervening
sequence point (the assignment and the post-increment). Since it's undefined
what should happen in such a case, a compiler is permitted to do anything,
which is what you're seeing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Found something odd with the increment operator. When incrementing after a
multiply by an odd literal number, it increments after the assignment. When
incrementing after a multiply after an even literal number, or after a
multiply by a variable with either an odd or even number, the final increment
is not performed.
Yes, I am aware the programming practice is poor in this case (both assignment
and increment of the same variable in the same statment). But shouldn't it be
consistent?
Example code follows:
By the way, when this code is executed in MSVC 2010 Express, the output is as
one would expect, the number 5 in the first two cases, and the number 7 in the
last two cases.
I ran this code using Lcc-Win32: ( not using code tags, as they suck on this
forum):
include <stdio.h>
int main()
{ int value;
int a;
a = 2;
value = 2;
value = 2 * value++;
printf("value=%d\n", value);
value = 2;
value = a * value++; // variable even
printf("value=%d\n", value);
a = 3;
value = 2;
value = 3 * value++; // literal odd
printf("value=%d\n", value);
value = 2;
value = a * value++; // variable odd
printf("value=%d\n", value);
system("PAUSE");
return 0;
}
The result were: 4, 4, 6, 6
I believe I correctly unscrambled your code.
@sarbayo,
Thanks for responding.
Your rendition of the code seems correct. Not seeing the "scrambling" you are.
Both versions look OK on my browser.
Didn't it suprise you that you didn't get 5,5,7,7 as the output?. Isn't the
post increment operation supposed to trump the assignment operator?
If the final post-increment operation is supposed to be disregarded, can you
provide a link to where that is stated as the intended behavior of C++?
I ran the same example as above on Pelles-C,
with the result: 4, 4, 6, 6
I then ran the same example on VC-2008,
with the results: 5, 5, 7, 7
@ejohnson3
it is interesting.
Dev-C++'s compiler is based on GCC.
Lcc-Win32 and Pelle's-C are based on LCC.
It's clearly not a Dev-C++ bug as it extends beyond Dev-C++.
I don't think "post increment" trumps the assignment.
Logic would dictate that "value" would be incremented, "post assignment".
ie: a = 3, value = 2, value = (a * value), value++
at least, that's what VC is doing.
Lcc, Pelle, and DevC are failing to increment at all.
@sarbayo,
Thanks for trying some other compilers. DEV-C++ is incrementing in one special
case, the literal odd number. The other compliers (non VC) you reported on are
failing to increment in all four cases.
I find it strange that the compiler is sensitive in this way.
@ejohnson3
I experimented with "pre-increment" as well:
++value
and that didn't work either.
BTW, this forum gets very little attention these days, since Dev-C++ is no
longer maintained.
I seldom visit here, 2-3 times a month maybe. I would recommend the following
link:
http://cboard.cprogramming.com/
for any further inquiries.
You can search the archives without joining, but, you have to join to be able
to post there.
Beware the "flames" tho.
@sarbayo,
Thanks for the tip about the cboard. I'll check it out.
Your example code exhibits undefined behavior - that's why various compilers
give various results - there's no such thing as a correct result.
You have the variable
value
modified more than once without an interveningsequence point (the assignment and the post-increment). Since it's undefined
what should happen in such a case, a compiler is permitted to do anything,
which is what you're seeing.