>From: Will Adams [mailto:wadams@freescale.com] > >The expression `h == null || h.data == 5' requires short-circuit >evaluation to avoid an illegal null dereference. Situations involving && and requiring short-circuiting may seem more natural than ones involving ||. However, ones involving || can come up quite easily. Applying DeMorgan's law to an expression involving && that requires short-circuiting, can result in an expression involving || that requires short-circuiting. Will's example is a case of this, where !(h != null && h.data != 5) would be clumsy and hard to read. Unlike &&, you cannot get the effect of a short-circuiting || just by a simple nesting of if-statements. >I think the Standard should be changed as follows. > >(A) Operators `&&', `||' and `?:' are short-circuiting. I think we are already OK on `?:'. Section 4.1.13 says that if expression 1 is false, then expression3 shall be evaluated and used as the result. It does not say that expression2 can also be evaluated. Similarly, if expression1 evaluates to true, then expression2 is evaluated and used as the result. It does not say that expression3 can also be evaluated. For an unknown condition, both expression2 and expression3 are evaluated. So it already describes evaluating only the expression(s) selected. >(B) Other operators must evaluate all their operands, in any order. Requiring evaluation of other operands is fine (though of course an implementation need not actually do so if it can guarantee equivalent behavior). However, the LRM specifies an evaluation order. Relaxing this would insert indeterminacy, which we are trying to reduce. Note again that an implementation is free to pick any actual order it likes, as long as the behavior is the same as the specified order. So this does not constrain implementations except in the cases where it would affect behavior. And in those cases, you want to specify what the behavior should be. >An implementation is allowed to avoid evaluating `a' in `a & b' when `b' > >is 0, provided evaluating `a' has no observable side-effects. This has >the same observable effect as applying rule (B). There is no need to specify this. The LRM can only specify the behavior of the language, not the implementation technique. Any implementation that produces the specified behavior is compliant, regardless of its internal details. So if short-circuiting or changing the evaluation order has no visible effects, an implementation is free to do so as an optimization. After all, how can you prove it is noncompliant? Steven Sharp sharp@cadence.comReceived on Tue Aug 15 16:49:48 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 15 2006 - 16:49:53 PDT