visual c++ funny or its a bug?
-
Now ppl this is funny!
int var=10; cout<< (var++ * var++) ;it should print 110 but it actually doesn't. it prints 100 ;) but it works correctly (prints 110) on c#, java compilers and other c++ compilers.With VC++ 6.0, the result here is 100. (One hundred.) And I think "One hundred" is a correct result. Because when such an expression: int var = 10; cout << (var++ * var++); is equal to: int var = 10; cout << (var * var); var = var + 1; var = var + 1; // var = 12 now. Maxwell Chen
-
With VC++ 6.0, the result here is 100. (One hundred.) And I think "One hundred" is a correct result. Because when such an expression: int var = 10; cout << (var++ * var++); is equal to: int var = 10; cout << (var * var); var = var + 1; var = var + 1; // var = 12 now. Maxwell Chen
Yes even i do get 100 Cos v++ is equivalent to a post increment so the answer should be v*v & the value of v is then updated to 12
-
With VC++ 6.0, the result here is 100. (One hundred.) And I think "One hundred" is a correct result. Because when such an expression: int var = 10; cout << (var++ * var++); is equal to: int var = 10; cout << (var * var); var = var + 1; var = var + 1; // var = 12 now. Maxwell Chen
No I don't think so, the results should be 110 because unary operators has higher precedence over binary operators, the correct steps will be as follwing: At the beginning
varis 10. 1, calc the first "var++", result is 10 andvarbecomes 11. 2, calc the second "var++", result is 11 andvarbecomes 12. 3, calc the product of the first result(10) and the second result(11), which is 110. At the endvaris 12. -
No I don't think so, the results should be 110 because unary operators has higher precedence over binary operators, the correct steps will be as follwing: At the beginning
varis 10. 1, calc the first "var++", result is 10 andvarbecomes 11. 2, calc the second "var++", result is 11 andvarbecomes 12. 3, calc the product of the first result(10) and the second result(11), which is 110. At the endvaris 12.Maxwell Chen is right. The result should be 100. Post-Increment means "Increment this variable after the operation the post-increment is used in". So a = b++ means "A = B. Increment B." and a= b++ * c++ means "A = B multiplied with C. Increment B. Increment C." Cheers Sebastian
-
No I don't think so, the results should be 110 because unary operators has higher precedence over binary operators, the correct steps will be as follwing: At the beginning
varis 10. 1, calc the first "var++", result is 10 andvarbecomes 11. 2, calc the second "var++", result is 11 andvarbecomes 12. 3, calc the product of the first result(10) and the second result(11), which is 110. At the endvaris 12.u know * is Preeminent than ++ so at first RESULT will set to (Var * Var). but var++ will not change the result so result = (10*10) = 100 and val will updated to 12
-
No I don't think so, the results should be 110 because unary operators has higher precedence over binary operators, the correct steps will be as follwing: At the beginning
varis 10. 1, calc the first "var++", result is 10 andvarbecomes 11. 2, calc the second "var++", result is 11 andvarbecomes 12. 3, calc the product of the first result(10) and the second result(11), which is 110. At the endvaris 12.You might be confused... ;) Regarding to the example: cout << (var++ * var++); The meaning of "precedence" is, to take the expression as: cout << ((var++) * (var++)); // Means that parsing the postfix ++ token first. // Not means that counting the result of postfix ++ operation. rather than cout << ((var++) (*var)++); // Wrong. since operator * (Multiplicative) has lower precedence than operator ++ (postfix). Maxwell Chen
-
You might be confused... ;) Regarding to the example: cout << (var++ * var++); The meaning of "precedence" is, to take the expression as: cout << ((var++) * (var++)); // Means that parsing the postfix ++ token first. // Not means that counting the result of postfix ++ operation. rather than cout << ((var++) (*var)++); // Wrong. since operator * (Multiplicative) has lower precedence than operator ++ (postfix). Maxwell Chen
-
:-D Maxwell Chen
-
Now ppl this is funny!
int var=10; cout<< (var++ * var++) ;it should print 110 but it actually doesn't. it prints 100 ;) but it works correctly (prints 110) on c#, java compilers and other c++ compilers.C++ only guarantees that all side-effects are complete by the point that a sequence point is reached. All function arguments must be evaluated before a function is called, but order of evaluation of the function arguments is implementation-defined. Visual C++ clearly evaluates
varonce, then performs the multiplication, then the post-increments. This looseness allows the compiler to produce more optimal code in some circumstances. C# and Java have strict left-to-right evaluation, so your code does work as you are expecting with those languages. -
Now ppl this is funny!
int var=10; cout<< (var++ * var++) ;it should print 110 but it actually doesn't. it prints 100 ;) but it works correctly (prints 110) on c#, java compilers and other c++ compilers.Modifying var more than once between sequence points results in undefined behavior in C++. A C++ compiler can generate whatever results it wants from this. You could get 100, 110, 121, or any other value. Any result produced can't be considered correct or wrong - it is undefined.
-
Now ppl this is funny!
int var=10; cout<< (var++ * var++) ;it should print 110 but it actually doesn't. it prints 100 ;) but it works correctly (prints 110) on c#, java compilers and other c++ compilers.if the program is: int var = 10; cout<<(var++ * var++); the result is 102 :omg: and if the program is like this: int var = 10; cout<<((var++)*(var++)); the result is 100; what i think is first the mutiplication operation is being taken place and the varible is getting incremented. in vc++ programming guide present in MSDN library unary operator (post increment) has the highest precedence ok u know the problem y it is happening pls send a mail
-
C++ only guarantees that all side-effects are complete by the point that a sequence point is reached. All function arguments must be evaluated before a function is called, but order of evaluation of the function arguments is implementation-defined. Visual C++ clearly evaluates
varonce, then performs the multiplication, then the post-increments. This looseness allows the compiler to produce more optimal code in some circumstances. C# and Java have strict left-to-right evaluation, so your code does work as you are expecting with those languages.nicely explained but i am still not completely satisfied :(. just because when i implement my own class "myint" which has the post increment, the multiplication and the assignment operators overloaded and i use them as:
myint a(10); myint c=(a++ * a++);i get value of c as 110 but when i use int i.e:int a=10; int c=(a++ * a++);i get c as 100 why this??? secondly in the case of cout<<(a++ * a++) u can say that (a++ * a++) comes under the case of "evaluation of function order" (though i don't agree) but when we useint c=(a++ * a++) ;it does not come under "evaluation of fuction order" it comes under "operator precedence" case, and it seems as if vc++ is voilating some rules. for ur information the "evaluation of function order" case is as: int a=1; cout< -
nicely explained but i am still not completely satisfied :(. just because when i implement my own class "myint" which has the post increment, the multiplication and the assignment operators overloaded and i use them as:
myint a(10); myint c=(a++ * a++);i get value of c as 110 but when i use int i.e:int a=10; int c=(a++ * a++);i get c as 100 why this??? secondly in the case of cout<<(a++ * a++) u can say that (a++ * a++) comes under the case of "evaluation of function order" (though i don't agree) but when we useint c=(a++ * a++) ;it does not come under "evaluation of fuction order" it comes under "operator precedence" case, and it seems as if vc++ is voilating some rules. for ur information the "evaluation of function order" case is as: int a=1; cout<The C++ standard (ISO 14882:1998) at section 5, paragraph 5 reads: Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined. Example:
i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incrementedAll that C++ guarantees is that the side-effects of evaluating an expression are complete by the next sequence point - it does not specify an order of evaluation of terms in an expression, except where operator precedence is involved. The second example above works because the comma operator introduces a sequence point. The exact text in the standard regarding sequence points is in section 1.9, paragraph 7, and reads: Accessing an object designated by a
volatilelvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. However, an overloaded operator is treated in the same way as a function call. There is a sequence point between evaluating the arguments for a function call and the actual call itself, and at the end of each statement. In the case ofmyint, the compiler essentially generates:myint c = (a.operator++(int)).operator*(a.operator++(int));
The two calls to
operator++are therefore executed before the call tooperator*. In the second case I would argue that the compiler appears to have generated the wrong code, because function calls are being generated, and << is left-associative. Again, the mapping is something like:((cout.operator<<(a++)).operator<<(a++)).operato