Hello Helen,

Friday, June 13, 2003, 1:58:04 AM, you wrote:

HB> At 11:00 AM 13/06/2003 +0700, you wrote:

>>Leyne, Sean wrote:
>> >>and can't come up with any scenario where subsequent OR
>> >>conditions could override a preceding True...
>> >
>> > I completely agree! Would suggest that this be dropped in the v2.0
>> > release.
>>
>>Of course
>>
>> True OR (anything...)
>>
>>will always still be True. This is not about determining final truth
>>value, but about side effects. I used to remember that they have an
>>option like this in Turbo Pascal (and perhaps still do in Delphi).
>>Sometimes when a programmer writes:
>>
>> if (x=1) and (someFunc(x)=2) then begin
>> ...
>> end
>>
>>he expects someFunc() to _always_ be evaluated, no matter what the value
>>of x is. someFunc() might do stuffs that have side effects. In these
>>cases, complete boolean evaluation makes a difference.

HB> AFAIK, ANDed conditions that are not conditioned by OR with a higher
HB> precedence are *always* evaluated.

Actually, no. Unless specified by the compiler(in Delphi's case), read
Delphi's help on Complete Boolean Evaluation. The option applies to
both AND and OR. In an AND sequence, the short-circuit happens at the
first FALSE comparison. In an OR sequence, it happens at the first
TRUE comparison. Using David's example, if x equals 2, then
somFunc(x)=2 will not be evaluated, if the evaluation is
short-circuited. It would be evaluated by using complete boolean
evaluation.

--
Best regards,
Daniel