Assignment operator unusual behaviour

Question

0.00/5 (No votes)

See more:

I am writing a piece of code and compiling in two different compilers

int i = 1;
i++;
int y = ++i * ++i * ++i;
cout<<"the value of y is"<<<y;>

The two compilers are turbo C++ and Microsoft Visual Studio 2010.

But in turbo C the out put of the code is y = 60

where as in MS VS 2010 the output is y = 125

I am not really new to C++, but the output of Turbo C has confused me of what is right.

Is that both are right?

Can someone please explain the situation in both the cases.

My hearty request to you, please don't give link to other "question and answers in codeproject" as I have already seen in some other Programming helper related sites, instead of giving me correct answer they closed the question saying it duplicate. sad but true.

Just enlighten me. may be you are good but I am not.

I am running this is windows 7 32bit OS.

Thanks

Deb

Posted 5-May-12 8:32am

Deb Kumar Ghosal

Add a Solution

Comments

Sergey Chepurin 5-May-12 16:15pm

Pre-increment has a higher precedence level (3) over multiplication (5), thus, it is done first by compiler. See the table of precedence levels and associativity rules[^]

4 solutions

Solution 4

Bit late to the party I know, but I couldn't see anyone mention sequence points in the previous answers. Sequence points are places where according to the language standard the compiler has to have evaluated all the sub-expressions in a statement.

I can never remember the rules for sequence points but a good rule of thumb in C++ '98 and '03 is to not modify the same variable in more than one sub-expression on the RHS of an assignment. If you do the compiler can (and will) do just about anything! Wikipedia[^] has a good description of sequence points in C and C++ which should give you handle on why you get the result you do.

Cheers,

Ash

Posted 8-May-12 4:43am

Aescleal

Updated 8-May-12 5:53am

Solution 3

Thank you very much for the answers and explanation from both of you.

Whatever you said is correct, and Microsoft compiler or turbo C compiler free to do whatever it should do.

I also agree that nobody in their free mind write a code like this. And we should avoid to write such kind of code.
I was just checking a piece of code and thought to check it by turbo C, I was surprised by the two different outcomes.

So a little bit brain storming...
Anyways by your answers I come to know that its compiler behavior which results differently.

Thanks
Deb

Posted 5-May-12 9:09am

Deb Kumar Ghosal

Comments

Code-o-mat 5-May-12 15:17pm

Yourwelcome. :)

JackDingler 7-May-12 12:05pm

Turbo C and the latest MS Compilers are also written to different ANSI Specifications.

The committee tries hard not to propose changes that produce side effects like these, but it does happen. Normally, these things are documented well and in the release and upgrade notes. And perhaps this was.

I don't know if that's the case here or not. Differences in compilers, for these corner cases can be expected. And that's why it's best to make your code as clear as you can, so it's obvious what you expect.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Chuck O'Toole · Accepted Answer · 2012-05-05T08:53:00

the ++ operator is defined to either "pre-increment" before the expression is used or "post-increment" after the expression is used. In your case, it's the "pre-increment" case.

The problem is that the compilers are free to decide when the "expression is used".

Obviously, Turbo C decides that each use of "++i" is a separate expression so before using "i", it is pre-incremented. So, the expression is really

int y = 3 * 4 * 5

which gives 60.

Microsoft decides that the expression is the whole statement so each "++i" is causes "i" to be incremented before the entire expression is used. Therefore the expression is really

int y = 5 * 5 * 5

which gives 125.

While this in an interesting classroom exercise in the language definition, nobody in their right minds uses pre- or post- increment or decrement like this. At least nobody in their right mind hires someone who writes code like this.

So chalk this up as an example of how different compilers are allow to interpret thing in the spec their own way and use it as an example of things to avoid doing.

Code-o-mat · Accepted Answer · 2012-05-05T09:05:00

Apparently turbo C does this (we agree on that i equals 2 when it gets to your y=... expression):
1. it increments i by one, it will be 3
2. it increments i by one again, ii will be 4
4. it multiplies 3 and 4 and gets 12
5. it increments i by one again, it will be 5
6. it multiplies 12 by 5 and gets to the result: 60

So basically it breaks the expression ++i * ++i * ++i down to something like this:

++i; //i is 3
y = i; //y is 3
++i; //i is 4
y = y * i; //y is 3 * 4 = 12
++i; //i is 5
y = y * i; //y is 12 * 5 = 60, done

The MS compiler on the other hand does this:
1. it increments i by one 3 times, since it "sees" three ++i statements, it will be 5
2. multiplies 5 by 5, gets 25
3. multiplies 25 by 5 and gets to the result: 125

So this would be something like:

++i; //i is now 3
++i; //i is now 4
++i; //i is now 5
y = i * i * i; //y is 5 * 5 * 5 = 125, done

It is all a question of execution order. As far as i know, there is no standard that declares the order in such a situation, thus, both compilers are correct, they just interpret the expression differently. This is why if you want to write easily portable code, you should try to avoid such situations.

Assignment operator unusual behaviour

4 solutions

Solution 1

Solution 2

Solution 4

Solution 3

Add your solution here

Preview 0