Author: Robert Hyatt
Date: 07:52:27 01/19/06
Go up one level in this thread
On January 19, 2006 at 05:53:10, Walter Faxon wrote: >On January 18, 2006 at 17:59:27, Robert Hyatt wrote: > >>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.. > > >Isn't: > if ((a < b) && (i++ < 0)) ... > >Just shorthand for: > if (a < b) > if (i++ < 0) ... > >I believe you have been misled by the two tests appearing in the same "if" >statement. Surely you don't program to avoid an out-of-bounds reference in a >case that follows a guard that explicitly prevents it. > >C has a funny restriction here. The Standard disallows computing expressions >such as &table[-1] (unless table[] is known to be part of something having a >prior element) _even if the resulting value is never dereferenced!_ But if the >flow of control doesn't compute the expression in the first place, all should be >ok. > >-Walter Yes, but remember that I am not concerned with "evaluating" the expression. I'm concerned with allowing the compiler to pre-fetch the value so that if necessary, it can do the evaluation at no cost with respect to reading from memory. I'm not real big on things like if (i>=0) && (i < dim_x) && x[i] > 0) in my code. If the compiler waits to load x[i] until after it evaluates all the crap to the left, we are going to add in several hundred clock cycles of latency, where if it can pre-fetch the value before getting anywhere near the condition test, those clock cycles are covered up and we don't see the penalty. > > >> >>> >>> 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.