>>>>In one of my apps I just found and fixed a subtle edge-case bug caused by short-circuiting of logical operators. With my coding style I'm not usually vulnerable to it so it was interesting to be reminded of this feature of VFP.
>>>
>>>Whoever needs the reminder... it's been drilled into me that any compiler will shortcircuit your logicals, period. And I take that into account whenever I'm coding. I've seen a few experienced guys do things like this
>>>
>>>

do case
>>>   case not .FirstProcessGoesWell()
>>>   case not .SecondProcessGoesWell()
>>>...
>>>   case not .LastProcessGoesWell()
>>>   otherwise
>>>      oMsg.Message("all is well")
>>>endcase

>>>...which is, for me, perhaps the neatest packaging of multiphase batch process, which needs to be abandoned on first critical error. Can't remember whom I first saw doing this, perhaps the Feltmans or someone around the ComCodebook project. This is shortcircuiting by design.
>>>
>>>However, I've found a case where I'd expect shortcircuiting to work, but it doesn't. It's the evl() and nvl() functions, where both parameters are evaluated, regardless of what the first one returns. So if you try
>>>
>>>xx=evl(call1(), call2())
>>>
>>>call2 will be called no matter what call1 does. This is kind of counterintuitive, because the equivalent construct with iif() will not have this side effect.
>>
>>Nice post, thanks.
>>
>>Many years ago I read some articles in Byte mag or DDJ or some such, about the tricks C/C++ optimizing compilers employ. Coupling that with the knowledge that not all languages short-circuit the same way (or at all) I made the decision that I would never rely on it regardless of language. From a maintenance POV I consider code that uses it fragile and a land mine for the unwary or unfamiliar. Relying on that behaviour is not inherently self-documenting in the way that (ideally) good code should be.
>
>Agree with the sentiment, but how do you stop a compiler from loop unrolling unless switching all optimizations off ?
>Dunno how you can avoid all such stuff (and yes, I try to elevate unchanged lines from the loop myself as well)

With something like C/C++ you can:

- As you suggest, turn off all optimizations
- Write code so good it can't be optimized further :)
- Rely on the compiler writer to not introduce optimization side effects to your program logic

VFP is a bit different, interpreted rather than compiled. Really it's p-code being run against precompiled runtimes - VFP and VC++. VFP was designed to run on a wide range of low-end hardware so I suspect the flags used to compile the runtime are very conservative. I also suspect the VFP "compiler" (p-code generator) may do no advanced optimizations at all. My guess with VFP is we don't have to worry about it.