On 11/10/2010 08:40 AM, Stephen Wille Padnos wrote: >> >> Okay, I see I'm not being clear on what I'm trying to say here. >> > I don't think that's the problem :) You're being quite clear. > >> In C, >> there are only two operators that determine whether an expression is a >> short circuit evaluation or not -&& and ||. >> >> > The question was whether the expression is a short-circuit trick, and > the term "short circuit" may not have been used correctly. Hence the > question. > >> So, this is a short circuit eval - if(new_in&& new_in != start_in) and >> so is this - if(new_in || new_in!= start_in). >> >> This is not a short circuit eval - if((new_in&& new_in) != start_in, >> nor is if ((new_in || new_in) != start_in). >> >> C syntax knows that the&& or || needs to be evaluated before the >> conditional operator in the second expression to determine if the second >> expression is even evaluated if the first expression is false. >> >> > Operator precedence is still important, regardless of whether an > expression can be short-circuited or not. > Yes, but... The short circuit is always an evaluation between two or more expressions. There is no short circuit eval with only one expression, or an expression separation operator other than either && or || (in C code of course - other languages are different). The separator is what makes this a special case, and it's read as both an operator and an expression separator for the "short circuit" purposes. > I think Andy was pointing out that it's the operator precedence rules > that determine what the expression actually says. > > if (a&&b>c) could be interpreted two ways: > if ((a&7b)>c) (incorrect) > if (a&&(b>c)) (correct) > The compiler would see that first statement as a short circuit eval, and always correctly evaluate it as your second form. > The sense of the expression is determined by operator precedence > (logical&& is lower than mathematical comparison>). After the sense > of the expression is determined, code may be generated which will only > evaluate enough terms to unconditionally determine the outcome of the > expression. (I don't remember if short-circuit evaluation is required, > but it may be. I recall a discussion about the form "if (ptr&& > ptr->x)", which will only protect the code from null pointer > dereferencing with short-circuit evaluation) > But, depending on the operator, either && or ||, the entire expression is evaluated differently. If the conditional operator is &&, then the second condition is evaluated if, and only if, the first returns true. If it returns false, the second expression is never evaluated. On the other hand, if the short circuit operator is || then both expressions will always be evaulated. In both of these cases, the && or || operator acts as an expression separator. The expression you mention "if(ptr && ptr -> x) only gets fully evaluated if ptr is true. In any of these cases, the referencing or de-referencing should only happen in the "then" part of the statement. > So you and Andy have been clearly explaining two different things at > each other :) > Yes, and the answer is 42... ;-) > - Steve
mark ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
