Mark Wendt wrote: > On 11/10/2010 07:46 AM, Andy Pugh wrote: > >> I don't think that Kirk was talking about "Short circuit evaluation" >> in this sense. I think he was puzzled by what the phrase >> "new_in&& new_in" was doing. Perhaps he could chime in and clarify. >> >> I disagree about the importance of operator precedence in this case. >> If&& had a higher precedence than != then the functional behaviour of >> that "if" statement would be quite different. >> >> With actual C precedence: >> new_in 0 1 0 1 >> start_in 0 0 1 1 >> result 0 1 0 0 >> >> with&& having higher precedence than != (new_in&& new_in) becomes an >> accidental cast-to-boolean: >> >> new_in 0 1 0 1 >> start_in 0 0 1 1 >> result 0 1 1 0 >> >> > 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.
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 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) So you and Andy have been clearly explaining two different things at each other :) - Steve ------------------------------------------------------------------------------ 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
