Order Of Evaluation Question

[der]

Hello all,

I've a question about order of evaluations in expressions that have && and
|| operators in them.

The question is: will the evalution go left-to-right, no matter what -- even
if the || operator is before the && operator? e,g,
In an expression like a = (z>x) || (x<0) && (z-y>9);

is it guaranteed that z>x will be checked first?
is there a difference between expressions thats have || and && operators,
then those who don't?
in this expression: a = f() + g(); it isn't guaranteed that f() will be
called first, so I want to know whether it is the same with || and &&
operators.

Thanks for your help.

 

[Markku Kolkka]

<lähetetty & postitettu>

I've a question about order of evaluations in expressions that have && and
|| operators in them.

The question is: will the evalution go left-to-right, no matter what --
even if the || operator is before the && operator?

No, operator precedence dictates the evaluation order, only logical
operations at same precedence level are executed left-to-right.

In an expression like a = (z>x) || (x<0) && (z-y>9);

is it guaranteed that z>x will be checked first?

No, it's guaranteed that x<0 is evaluated first.

is there a difference between expressions thats have || and && operators,
then those who don't?

Yes.

 

[Derk Gwen]

# Hello all,
#
# I've a question about order of evaluations in expressions that have && and
# || operators in them.
#
# The question is: will the evalution go left-to-right, no matter what -- even
# if the || operator is before the && operator? e,g,
# In an expression like a = (z>x) || (x<0) && (z-y>9);

In an expression like (p) || (q), (p) will be evaluated and only if false will
(q) be evaluated. For (p) && (q), (q) is only evaluated if (p) is true. && has
a higher precedence that ||, so the fully parenthesised version of your predicate
is
(z>x) || ((x<0) && (z-y>9))
so the evaluation order is
valueof (z>x) || ((x<0) && (z-y>9))
= if (z>x)
then true
else
valueof (x<0) && (z-y>9)
= if (x<0)
then
if (z-y>9)
then true
then false
else false

# is it guaranteed that z>x will be checked first?
# is there a difference between expressions thats have || and && operators,
# then those who don't?

'||', '&&', '?:', and ',' serialise the evaluation of operands. '||', '&&', and
'?:' might not evaluate all their operands. ',' serialises, evaluating its left
operand and then its right. Other operators do not have a standardised order of
evaluation, and they will evaluate all operands but the order of loads and
stores to do side effects is not defined by the standard.

 

[Christian Bau]

Hello all,

I've a question about order of evaluations in expressions that have && and
|| operators in them.

The question is: will the evalution go left-to-right, no matter what -- even
if the || operator is before the && operator? e,g,
In an expression like a = (z>x) || (x<0) && (z-y>9);

is it guaranteed that z>x will be checked first?

|| and && are special.

For both || and &&, it is guaranteed that the left side is evaluated
first, and all side effects of the left side will happen. Then the right
side will _only_ be evaluated if necessary; if you write (1 || <expr>)

 

[MiniDisc_2k2]

Please help me debug my program.
According to what you just said, the output should be
"Markku Kolkka is making sense."
but instead it says
"What the hell are you talking about?"


#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int a;
int z = -1;
int x = -2;
int y = 0;

a = (puts("What the hell are you talking about?"),
exit(EXIT_FAILURE), z>x)
||
(puts("Markku Kolkka is making sense."), x<0)
&&
(z-y>9);

return 0;
}

This is an example of trying to compress your code into too few lines and
then suffering the consequences. Try expanding the code a bit, I'll bet
you'll find the problem.

 

[Mark McIntyre]

This is an example of trying to compress your code into too few lines and
then suffering the consequences. Try expanding the code a bit, I'll bet
you'll find the problem.

I think pete knows that, its an ironic post.

 

[Chris Torek]

I've a question about order of evaluations in expressions that have && and
|| operators in them.

Several others have given correct answers (and one person a wildly
wrong one ). C does have a rule that is relatively easy to
remember here, though, and I think no one has yet described it.
That rule is: evaluation order is specified *only* by what C calls
"sequence points".

A compiler's job is to take some source-language description of
"what should happen" and re-arrange it, remove some of it, add to
it, and so on, so that some kind of computer hardware can make it
run as fast as possible. This slicing-and-dicing of your code is
allowed as long as the result is still what you originally asked
for. C compilers get to do this "cheaply" by piling up as much
action as they can between these "sequence points".

A sequence point is where the action stops. Stopping the action
makes "everything so far" finish, before the computer can go on to
"everything afterward". In other words, it establishes a particular
order of operations. (The compiler can still "slice and dice" your
code about, even across these sequence points, but *only* if it
can prove that you will not be able to tell that it has done so.
For instance, if you print output, that output must somehow magically
erase if it should not have been printed after all, and so on.)

This makes sequence points absolutely crucial, because as a C
programmer, you *need* to make sure things happen in specific
sequences. If you want to add 1 to i, or change p to point to
p->next, you *have* to have that happen before you use the new
values in i and p.

So the general answer to your question is that order of evaluation
is defined only if you have some of these "sequence points". Given
a sequence point, and some operation A that happens "before" and
some operation B that happens "after" that sequence point, every
C compiler must do A first, then do B (or, if it secretly slices
and dices things so that they happen simultaneously or in the other
order, it has to arrange an illusion, so that A *seems* to happen
before B, no matter what really goes on inside the machine).

in this expression: a = f() + g(); it isn't guaranteed that f() will be
called first...

Correct. Formally, the "+" and "=" operators have no sequence
points at all. (The function calls do have "embedded" sequence
points, but they are no help because we have no idea which function
gets called first.)

The question is: will the evalution go left-to-right, no matter
what -- even if the || operator is before the && operator? e,g,
In an expression like a = (z>x) || (x<0) && (z-y>9);

is it guaranteed that z>x will be checked first?

Here you are in luck. The C standard (either C89 or C99, there is
no real change here) says that the logical operators have sequence
points, and that given an expression with a logical operator, the
left hand side is evaluated first, then you get the sequence point.
If the result of the operator is now known, the right hand side is
not evaluated at all. (This "skip the other half if we know the
answer" technique is usually called "short-circuit evaluation".
Some other languages provide short-circuit evaluation too. For
instance, in Ada, one can write "if a and then b" to mean "test a;
then, only if the answer is not yet known, test b". Leaving out
the "then" -- "if a and b" -- allows the compiler to test both.
Paradoxically, it is actually sometimes faster to test both than
to skip one of the tests. These kinds of details are machine-dependent
though.)

Note that:

a = (z>x) || (x<0) && (z-y>9);

parses as:

a = (z > x) || ((x < 0) && ((z - y) > 9));

That is, the "&&" binds more tightly than the "||", and the "-"
in "z - y" binds more tightly than the ">" in "... > 9". So
what we have is a logical-OR-expression whose right hand side
is a logical-AND-expression. If you were to write instead:

a = ((z > x) || (x < 0)) && ((z - y) > 9);

you would have a logical-AND-expression whose left hand side
is a logical-OR-expression. Interestingly, while this changes
the overall result (and thus sometimes skips a different set
of evaluations), this has no effect on the evaluation *order*
if all sub-expressions are evaluated. (Exercise: why? Remember
that the rule is: "evaluate left side, then have a nice nap at a
sequence point, then evaluate right side only if necessary".)

 

[Christian Bau]

This is an example of trying to compress your code into too few lines and
then suffering the consequences. Try expanding the code a bit, I'll bet
you'll find the problem.

This is an example of completely missing the joke. Read the original
post, Markku's reply, and this point, and try to understand what is
going on here. If you don't get the joke, I will be quite willing to
explain it.

 

[Steve Summit]

No, operator precedence dictates the evaluation order, only logical
operations at same precedence level are executed left-to-right.

Wherever did you get that idea?

As a general rule, operator precedence does *not* dictate
evaluation order, and imagining that it does is a sure way to
get yourself in trouble. Mis-answering a question like this is
not the usual result of the mistaken assumption that operator
precedence does dictate evaluation order, but I guess it's
still a confirming instance of the general rule.

See http://www.eskimo.com/~scs/readings/precvsooe.960725.html
for more on this.

Yes.

No, it's guaranteed that x<0 is evaluated first.

No.

Steve Summit
(e-mail address removed)

29743382636026269132079478342650468004927