> Geoff Wedig wrote:
>> 
>> J?r?me Grimbert <jgr### [at] atos-groupcom> wrote:
>> 
>> > No, he wants the behavior the C compiler has when evaluating:
>> 
>> >  if ((divisor !=0)&&(amount/divisor ...
>> 
>> > That is: if the divisor is 0, the division is not even performed
>> > because the left part of the '&&' is false.
>> 
>> > Sincerely, I'm against this idea for POV.
>> > (it's ok in C).
>> 
>> Oh, why?  Why should POV do extra work when the result is going to be false
>> already? The reason it's done in C is to avoid that extra work.  Why would
>> this be a bad thing?  The only case I can think of is if there are side
>> effects to the second half of the equation (it calls a macro that creates an
>> object and returns a value), but that's so rarely necessary, plus needlessly
>> confusing (try figuring out code that has such side effects six months later
>> or which you didn't write) that it's not something that we really need.

> You said it: it would open the door to needlessly confusing code.

No, my *counterexample* (ie, the only reason you want anything else) is
needlessly confusing, because of side effects.  Having a pair of boolean
expressions that terminates if the first expression determines the whole
sequence is quite sensible.

I don't see why using two ifs is any clearer, it's just verbose, which is
its own kind of obtusification.

Geoff

Post a reply to this message