&& and || -- precedence evaluation doubt

R

Roshan Mathews

According to the precedence rules && has a higher precedence than
|| and both are 'left to right' associative. So in an expression
like

++i || ++j && ++k

where i, j, k are 0, -1, 0 (before the expression is evaluated),
shouldn't the && part be evaluated before the || part? In which
case will the evaluation be stopped short if the right side
evaluates to 1 (true)?

Or is the evaluation of this expression implementation dependent?
 
E

Eric Sosman

Roshan Mathews wrote On 04/18/06 11:54,:
According to the precedence rules && has a higher precedence than
|| and both are 'left to right' associative. So in an expression
like

++i || ++j && ++k

where i, j, k are 0, -1, 0 (before the expression is evaluated),
shouldn't the && part be evaluated before the || part? In which
case will the evaluation be stopped short if the right side
evaluates to 1 (true)?

Precedence is not evaluation order. (Don't feel bad;
many others have confused the two.) Precedence says that
the expression above means the same as

++i || (++j && ++k) /* RIGHT */

rather than

(++i || ++j) && ++k /* RWONG */

Once the meaning is determined (by precedence or by
explicit grouping or by a combination), the evaluation
proceeds. For this expression, ++i is evaluated first.
Since it turns out to be non-zero (for the given values),
the rest of the expression is not evaluated at all, and
the result of the expression is 1.
Or is the evaluation of this expression implementation dependent?

No.
 
R

Richard Bos

Roshan Mathews said:
According to the precedence rules && has a higher precedence than
|| and both are 'left to right' associative. So in an expression
like

++i || ++j && ++k

where i, j, k are 0, -1, 0 (before the expression is evaluated),
shouldn't the && part be evaluated before the || part?

No. This higher precendence means nothing more than that a || b && c is
equal to a || (b && c), not to (a || b) && c. It says nothing about the
order in which any of the operands are evaluated.
This is just as true of * and +, or of [] and ==. [] having higher
precedence than == means that x == y[z] does evaluate to x == (y[z]),
not to the (nonsensical) (x == y)[z]. It does not mean that y and z are
evaluated before x.

There is a special case, however, for the && and || operators, which
guarantees the opposite of your what you suppose. They are said to
short-circuit; that is, they are required to be evaluated left-to-right,
and when the value of the entire expression is known, that value is
returned and no other operands are even looked at.
This means that ++i || ++j && ++k is handled like this:

Evaluate ++i. If this is true (non-zero), the whole expression is true
(to be precise, it is 1); stop here.
Ok, we now know that i used to be -1, and ++i was 0 (and since both
|| and && also introduce a sequence point, so is i, now; this is not
important in this example, but can be in other circumstances; e.g.,
it means that --i && a does not invoke undefined behaviour).
Evaluate ++j. If it is zero, the sub-expression ++j && ++k is zero,
and since ++i is also zero if we've got this far, so is the entire
expression; if so, stop here.
Now we know that ++i was 0 and ++j was non-zero.
Evaluate ++k. If it's false, the expression is false (0); if it's
true (non-zero), the expression is true (specifically 1).

Richard
 
K

Kenneth Brody

Roshan said:
According to the precedence rules && has a higher precedence than
|| and both are 'left to right' associative. So in an expression
like

++i || ++j && ++k

where i, j, k are 0, -1, 0 (before the expression is evaluated),
shouldn't the && part be evaluated before the || part? In which
case will the evaluation be stopped short if the right side
evaluates to 1 (true)?

Or is the evaluation of this expression implementation dependent?

Just because && has higher precedence than "||" doesn't mean that it
must be executed first, merely that the entire right-side must be
evaluated before or-ing it in. The entire boolean sequence still
needs to be evaluated left-to-right.

Your statement is equivalent to:

++i || ( ++j && ++k )

The "++i" is evaluated first. Because "++i" is non-zero, the rest of
the expression is not evaluated.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>
 
C

Christopher Benson-Manica

Richard Bos said:
There is a special case, however, for the && and || operators, which
guarantees the opposite of your what you suppose. They are said to
short-circuit; that is, they are required to be evaluated left-to-right,

Boring pedantic question: Are they required to really be evaluated
left-to-right, or must the implementation merely behave "as-if" the
arguments had been evaluated left-to-right?
 
D

Dik T. Winter

>
> Boring pedantic question: Are they required to really be evaluated
> left-to-right, or must the implementation merely behave "as-if" the
> arguments had been evaluated left-to-right?

Always as-if.
 
P

Peter Nilsson

Christopher said:
Boring pedantic question: Are they required to really be evaluated
left-to-right, or must the implementation merely behave "as-if" the
arguments had been evaluated left-to-right?

There is no 'merely' about it for a conforming implementation. :)

An implementation can replace...

i || j++ && 0;

....with...

if (!i) j++;

However...

i || 0 && j++;

....must be a no-op (assuming i is not volatile.)

the more classic case is something like...

if (p && *p)

Search for Chris Torek's posts on how an implementation can
'silently' trap by dereferencing a potential null pointer in parallel
to the null test, but it must 'cope' with that trapping and behave
as if it worked correctly.

There are circumstances involving volatile objects where a practical
conforming implementation must still be very careful about how it
handles the evaluation order of certain expressions.
 
R

Richard Bos

Christopher Benson-Manica said:
Boring pedantic question: Are they required to really be evaluated
left-to-right, or must the implementation merely behave "as-if" the
arguments had been evaluated left-to-right?

Well, of course, everything is as-if. However, that as-if had also
better involve not reading any volatiles, not calling rand(), not
causing any FP exceptions, and so on, and so forth. Your program really
must not be able to tell the difference in any reliable way. (Difference
in execution time, for example, does not count as reliable.)

Richard
 
A

Al Balmer

Boring pedantic question: Are they required to really be evaluated
left-to-right, or must the implementation merely behave "as-if" the
arguments had been evaluated left-to-right?
It's required that you not know or care ;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top