C++
-
I assume you are using Visual Studio. Put a break point on the code. Hit F5. When the break poin is reached, right click on the source to see a context menu having an item 'Go to Disassembly'.
I am in college and we are using Turbo C++. How can i perform the same here?? Thanks & Regards Pankaj
French is the language of love, for everything else there is c++ ...(anonymous)
-
I am in college and we are using Turbo C++. How can i perform the same here?? Thanks & Regards Pankaj
French is the language of love, for everything else there is c++ ...(anonymous)
I am sorry, I have no idea about how to do this in Turbo C. But you can take a look at the assembly code in my previous post to understand why 8 is displayed.
-
Hi All, follow the following code please: int i = 2; i = ++i + (++i) cout<French is the language of love, for everything else there is c++ ...(anonymous)
Pankaj D.Dubey wrote:
int i = 2; i = ++i + (++i) cout< Actually, 8 is just as a correct answer as 7. To research this, search for the term "sequence points". In ++i + (++i) for each ++i, i is first incremented, then the value is used. Also, the add will be done last. This does not fully define the order of evaluation of everything - and the implementation is free to choose the rest of the order. So it could do things in the order you were thinking of. Another equally valid order is: do the first increment ( i gets 3), do the second increment ( i gets 4 ), add current i to current i (8) The bottom line is that you shouldn't write expressions where parts of the expression have side effects that could alter the value of other parts of the expression.
Please do not read this signature.
-
Pankaj D.Dubey wrote:
int i = 2; i = ++i + (++i) cout< Actually, 8 is just as a correct answer as 7. To research this, search for the term "sequence points". In ++i + (++i) for each ++i, i is first incremented, then the value is used. Also, the add will be done last. This does not fully define the order of evaluation of everything - and the implementation is free to choose the rest of the order. So it could do things in the order you were thinking of. Another equally valid order is: do the first increment ( i gets 3), do the second increment ( i gets 4 ), add current i to current i (8) The bottom line is that you shouldn't write expressions where parts of the expression have side effects that could alter the value of other parts of the expression.
Please do not read this signature.
If i take another variable say 'Y' and perform the evaluation in that like Y = ++i + (++i); cout<French is the language of love, for everything else there is c++ ...(anonymous)
-
If i take another variable say 'Y' and perform the evaluation in that like Y = ++i + (++i); cout<French is the language of love, for everything else there is c++ ...(anonymous)
:confused:Exact same reason. You are using exactly the same expression on the right side of the equals sign. Since you didn't change anything relevant, nothing changed. Edit: Yes, you did change the expression on the left side of the equals sign and got a different answer, but the issue is unchanged.
Please do not read this signature.
modified on Wednesday, February 24, 2010 11:05 AM
-
:confused:Exact same reason. You are using exactly the same expression on the right side of the equals sign. Since you didn't change anything relevant, nothing changed. Edit: Yes, you did change the expression on the left side of the equals sign and got a different answer, but the issue is unchanged.
Please do not read this signature.
modified on Wednesday, February 24, 2010 11:05 AM
Exactly :) thanks mate, thanks a ton :) Thanks and Regards Pankaj
French is the language of love, for everything else there is c++ ...(anonymous)
-
Hi All, follow the following code please: int i = 2; i = ++i + (++i) cout<French is the language of love, for everything else there is c++ ...(anonymous)
It is safer not to use such code because you will get different results in different compilers. IIRC I got different results in VC 6.0 when compiled in Windows application and console application.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) -
It is safer not to use such code because you will get different results in different compilers. IIRC I got different results in VC 6.0 when compiled in Windows application and console application.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)Definitely it is not safe. Even the same compiler in different situations in the source code could produce different results, as the OP seems to have experienced. The relative order of evaluation including application of side affects isn't fully specified by the standard, so the compiler gets to pick what's convenient - and can pick differently in different places.
Please do not read this signature.
-
Definitely it is not safe. Even the same compiler in different situations in the source code could produce different results, as the OP seems to have experienced. The relative order of evaluation including application of side affects isn't fully specified by the standard, so the compiler gets to pick what's convenient - and can pick differently in different places.
Please do not read this signature.
The standard DOES have something to say on this. In the Expressions section introduction, it specifically states <quote>Except when noted, the order of evaluation of operands of individual operators is undefined. In particular, if a value is modified twice in an expression, the result of the expression is undefined except when an ordering is guaranteed by the operators involved. For example,
i = v\[i++\]; // the value if 'i' is undefined i = 7,i++,i++; // 'i' becomes 9</quote> [Stroustrup, 2nd ed, p492] So it's not that the standard fails to fully specify, it specifies that the result is undefined.
-
The standard DOES have something to say on this. In the Expressions section introduction, it specifically states <quote>Except when noted, the order of evaluation of operands of individual operators is undefined. In particular, if a value is modified twice in an expression, the result of the expression is undefined except when an ordering is guaranteed by the operators involved. For example,
i = v\[i++\]; // the value if 'i' is undefined i = 7,i++,i++; // 'i' becomes 9</quote> [Stroustrup, 2nd ed, p492] So it's not that the standard fails to fully specify, it specifies that the result is undefined.
It seems it is easy to fall into this trap especially when somebody is new to C++.
-
The standard DOES have something to say on this. In the Expressions section introduction, it specifically states <quote>Except when noted, the order of evaluation of operands of individual operators is undefined. In particular, if a value is modified twice in an expression, the result of the expression is undefined except when an ordering is guaranteed by the operators involved. For example,
i = v\[i++\]; // the value if 'i' is undefined i = 7,i++,i++; // 'i' becomes 9</quote> [Stroustrup, 2nd ed, p492] So it's not that the standard fails to fully specify, it specifies that the result is undefined.
Clarification/correction accepted. When I wrote "relative order ... isn't fully specified", I meant "is not fully dictated" (hence, as you say, is officially undefined) rather than "is not talked about".
Please do not read this signature.
-
It seems it is easy to fall into this trap especially when somebody is new to C++.
people seem to fall into traps like this -- when they try to be cool. there's no good reason to combine several distinct operations into single statement. one thing I've learned in my years is that 'cool is costly' -- you could spend many many hours trying to debug that mistake. write it simply and clearly (and readable) -- the compiler will optimize it for you. -p
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter Weyzen Staff Engineer [SoonR Inc -- PC Power delivered to your phone](http://www.soonr.com)