Printable View
This is the question for C++ expert, what will be the output of following codes and why?
Thanks a lot in advance!
Code:#include <iostream>
int main()
{
int a = 5;
int d = a++;
a = 5;
int b = a++ * ++a;
a = 5;
int c = ++a * a++;
a = 5;
int e = (a++) * (1);
std::cout << "b = " << b << std::endl;
std::cout << "c = " << c << std::endl;
std::cout << "d = " << d << std::endl;
std::cout << "e = " << e << std::endl;
}
I am not an expert ( but who is ? ).
The question about "what" can easily be answered by just running the program.
The question about "why" cannot fully be answered because of undefined behaviour.
Kurt
Yes, but I prefer you to think about the answer before run it in your platform.
I cannot answer why the output it is, so I think some expert can explain it. And thanks to explain more about "undefined behaviour", you mean the result will be different based on different platform and compiler?
Why 'undefined behaviour'? I think it's clear, isn't it?
Post-increment is performed after the expression is evaluated, and pre-increment before.
For example:First evaluated is ++a, so it becomes 6. Then it's performed b = a * a = 36, then a++, so becomes 7. Where is the 'undefined behaviour'?Code:int b = a++ * ++a;
Albert.
Like ZuK said, results are undefined in C++: http://parashift.com/c++-faq-lite/mi...html#faq-39.15
As far as I know * is not a sequence point it is possible that either ++a or a++ is evaluated first.
Kurt
yes, I guess it is the reason. Thanks a lot guys!
in the function operator , no compiler can guarantee that lhs will be processed before rhs, maybe that is why it is called"undefined behaviour".Code:int operator *(const int & lhs, const int & rhs);
:thumb: Kurt
Correct.
btw: This is one of the reasons to NEVER overload operators "&&" and "||". By specification the native versions "short-curcuit", and any overload will evaluate BOTH!!!
Ok, I thought it worked in different way. Thanks for explanation.Quote:
Originally Posted by Hobson
Albert.
First of all is good to return 0 because you use int main() and a value must be returned.++a increase the a by 1 and then use the new value of a in the expression.a++ use the current value in the expression and then increase the a by 1
No.. that would be unspecified behaviour (unspecified is not exactly undefined in the standards terms). Order of evaluation is unspecified. And that to the OP's code causes undefined behaviour because it is only defined that the side-effects of the increments (updating the variable storage included) will happen at a sequence point (here the semi-colon ; ). The evaluations of sub-expressions for those expressions could be interlaced with each other. Which means for this statement - int b = a++ * ++a, the following can happen in any order (events *a interfering with *b):Quote:
Originally Posted by ZuK
1a. read a for a++
2a. evaluate a++
3a. update storage of a after a++
1b. read a for ++a
2b. evaluate ++a
3b. update storage of a after ++a
Those operations themselves in their sub-expressions may be evaluated in order 1, 2, 3 but there can interference with each other. A write and a read or a write and a write without a sequence point causes undefined behaviour as per the standards. Hence, even a = a++; is undefined (two writes to the same variable without a sequence point in between).
No, this cannot be the reason as any overload would be a function call and function call is a sequence point. The result would be unspecified but not undefined.Quote:
Originally Posted by TheCPUWizard
Did you read any of the posts in this thread above before posting?Quote:
Originally Posted by tzimis
//Btw a similar issue came up on clc++m recently - http://groups.google.co.uk/group/com...b9275faa0ec230
If IS correct because an overload IS a function call. Both side would be evaluated. However the built in's are NOT implemented as function calls. Therefore you can doQuote:
Originally Posted by exterminator
If the ptr is NULL, then the evauation stops, and there is no (illegal) attempt to call Method1 on the (null) pointer!Code:if ((ptr) && (ptr->MethodIO))
{
}
I never thought of that before, but it does make sense that overloaded && and || cannot be 'lazy'.
That is indeed a good reason not to overload them, though I've never seen any point overloading them anyway.
i always make code like this:Quote:
Originally Posted by TheCPUWizard
i dont think its any diffrent..Code:if (ptr)
if(ptr->MethodIO)
{
}
however the evaluation stops at ptr, is this defined behavior by the standards?
The standard guarantees that the right-hand-side of && will not be evaluated if the left-hand side of && is false. Also the right-hand-side of || will not be evaluated if the left-hand side of && is true.
But if && or || is overloaded, that guarantee is lost because both sides need to be evaluated before operator&& or operator|| can be called, I think.
the link provided by exterminator explain one more factor, a++ and ++a can be evaluated at the same time, which can mess up the memory. :ehh: so maybe undefined behavior will be more correct than unspecified behavior.Quote:
Originally Posted by exterminator
Thanks!
Yes, it is.Quote:
Originally Posted by Mitsukai
&& also is a sequence point.Code:5.14 Logical AND operator [expr.log.and]
logical-and-expression:
inclusive-or-expression
logical-and-expression && inclusive-or-expression
1 The && operator groups left-to-right. The operands are both implicitly
converted to type bool (clause 4). The result is true if both operands are
true and false otherwise. Unlike &, && guarantees left-to-right evaluation:
the second operand is not evaluated if the first operand is false.
2 The result is a bool. All side effects of the first expression except for
destruction of temporaries (12.2) happen before the second expression is evaluated.