Order of evaluvation of parameters - defined?
I know that the order of evaluation of parameters within a function is not defined. How are parameters evaluated within an expression (if u can call them parameters)? Does the standard define this?
I came across a piece of code, which behaved indifferently. (Works sometimes, and again dosen't work sometimes)
if( (pSomeObject != NULL) && (pSomeObject->IsSomeCaseValid()) )
{
...
}
where, pSomeObject is a pointer to some Object :)
I fixed the same by nesting it into 2 if statements.
I would like to know does the standard define how expressions are evaluated.
# 1 Re: Order of evaluvation of parameters - defined?
Expressions are evaluated based on operator precedence. Do a google search, as I've always over parenthesized so as to avoid learning operator precedence for 50 different languages ;-)
That expression should work as intended so far as I can see. Is it possible that pSomeObject is not initialized to NULL in its declaration, or shortly thereafter? That would explain why it works sometimes, but not others; because if it's not initialized to NULL, it could contain anything at all... so it may not be NULL, but may not be a valid pointer either.
# 2 Re: Order of evaluvation of parameters - defined?
to avoid the question of operator precedence, i tried the same using parenthesis as above.
so basically what i want to know is....what gets evaluated first in this case
if( (A) && (B) )
A first or B first ??
where A & B are the two expressions as above
# 3 Re: Order of evaluvation of parameters - defined?
According to the convention - A get's evaluated 1st since for the && operator, the order is left to right.
See this msdn link ( http://msdn2.microsoft.com/en-us/library/126fe14k%28VS.80%29.aspx) on the subject.
Zachm at 2007-11-9 1:27:18 >
# 4 Re: Order of evaluvation of parameters - defined?
so it goes back to operator precedence...
thx
# 5 Re: Order of evaluvation of parameters - defined?
Operator precedence doesn't come into it. The operators && and || are specifically defined to be short-circuit operators - the first operand is evaluated, then, only if the value of the overall expression cannot be decided, is the second operand evaluated. That is, for &&, if the first expression evaluates to false, the whole expression must be false, so the second expression is not evaluated. Similarly, if the first expression of || evaluates true, then the whole expression must be true.
The comma operator defines a sequence point, so the expressions are evaluated in order.
All other operators have no defined evaluation order - not even precedence.
Note that user-defined operator&&, operator|| and operator, are function calls, so the short-circuit and sequence point properties do not apply. Hence, do not overload these operators or trouble will ensue.
The expression in the OP is guaranteed to work (and is, in fact, a very common idiom). If it fails to work correctly, then there is something wrong with the compiler.
# 6 Re: Order of evaluvation of parameters - defined?
thanks graham....very useful info!
some new words in my c++ dictionary now :)
# 7 Re: Order of evaluvation of parameters - defined?
All other operators have no defined evaluation order - not even precedence.
Does this mean, if i had a statement like this,
X = ( GetNumberOne() ) + ( GetNumberTwo() )
there is no guarantee which function is called first
# 8 Re: Order of evaluvation of parameters - defined?
Does this mean, if i had a statement like this,
X = ( GetNumberOne() ) + ( GetNumberTwo() )
there is no guarantee which function is called firstThere is no guarantee which is done first. The same thing with this:
SomeFunc(x,y);
If the argument x is an expression that may effect y or vice-versa, the code is ill-formed as there is no guarantee which parameters are evaluated first.
Regards,
Paul McKenzie
# 9 Re: Order of evaluvation of parameters - defined?
Does this mean, if i had a statement like this,
X = ( GetNumberOne() ) + ( GetNumberTwo() )
there is no guarantee which function is called first
Yep. In fact, consider:
x = (f1() * f2()) + f3();
You can't even trust f3 not to be called between f1 and f2
