Author: Robert Hyatt
Date: 14:59:27 01/18/06
Go up one level in this thread
On January 17, 2006 at 18:08:59, Dann Corbit wrote: >On January 17, 2006 at 18:01:16, Dann Corbit wrote: > >>On January 17, 2006 at 17:50:33, Dan Honeycutt wrote: >> >>>On January 17, 2006 at 14:59:15, Robert Hyatt wrote: >>> >>>... >>>> >>>>if (a && b) where if a is 0, b would not even be fetched usually... >>>> >>> >>>I thought, in this case, b _must_ not be fetched. >>> >>>Best >>>Dan H. >> >>3.5: But what about the && and || operators? >> I see code like "while((c = getchar()) != EOF && c != '\n')" ... >> >>A: There is a special "short-circuiting" exception for these >> operators: the right-hand side is not evaluated if the left-hand >> side determines the outcome (i.e. is true for || or false for >> &&). Therefore, left-to-right evaluation is guaranteed, as it >> also is for the comma operator. Furthermore, all of these >> operators (along with ?:) introduce an extra internal sequence >> point (see question 3.8). >> >> References: K&R1 Sec. 2.6 p. 38, Secs. A7.11-12 pp. 190-1; K&R2 >> Sec. 2.6 p. 41, Secs. A7.14-15 pp. 207-8; ISO Sec. 6.3.13, >> Sec. 6.3.14, Sec. 6.3.15; H&S Sec. 7.7 pp. 217-8, Sec. 7.8 pp. >> 218-20, Sec. 7.12.1 p. 229; CT&P Sec. 3.7 pp. 46-7. > >A place where the distinction could be important for the case at hand: > !(bfZwart[kol+1]&bfBoven[rij]) >could be if rij is an invalid address (negative or bigger than the dimention). >If the value of kol was always zero when rij was an invalid offset, then adding >1 would cause the exception to stop happening. > >Now, the bitwise operators do NOT guarantee left to right evaluation. Hence the >"usually" I think. But such an ordering is possible, just not required for >bitwise operators. Note the start of Semantics item 4 below... > I was thinking of the difference between "fetching" and "evaluating". If you do something like this: if ((a < b) && (i++ < 0)) I is supposed to be unchanged unless a is less than b. But that's a lousy way to program, _and_ I'm not aware of a thing that says the compiler can't pre-fetch i if it so chooses, and even increment it as well, just so it doesn't store it back until it is sure that a is less than b... I would write code with that in mind even if the ANSI C standard did dictate when things can be fetched, because there are lots of other programming languages that would blow up there as well.. > >©ISO/IEC ISO/IEC 9899:1999 (E) >6.5.13 Logical AND operator >Syntax >1 logical-AND-expression: >inclusive-OR-expression >logical-AND-expression && inclusive-OR-expression >Constraints >2 Each of the operands shall have scalar type. >Semantics >3 The && operator shall yield 1 if both of its operands compare unequal to 0; >otherwise, it yields 0. The result has type int. >4 Unlike the bitwise binary & operator, the && operator guarantees left-to-right >evaluation; there is a sequence point after the evaluation of the first operand. >If the first operand compares equal to 0, the second operand is not evaluated. >6.5.14 Logical OR operator >Syntax >1 logical-OR-expression: >logical-AND-expression >logical-OR-expression || logical-AND-expression >Constraints >2 Each of the operands shall have scalar type. >Semantics >3 The || operator shall yield 1 if either of its operands compare unequal to 0; >otherwise, it yields 0. The result has type int. >4 Unlike the bitwise | operator, the || operator guarantees left-to-right >evaluation; there is a sequence point after the evaluation of the first operand. >If the first operand compares unequal to 0, the second operand is not evaluated. >§6.5.14 Language 89
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.