I can't get VB to short circuit.
Does it simply not? If it does, what are it's priorities (left to right, right to left, precedence, et al)?
-Travis
Printable View
I can't get VB to short circuit.
Does it simply not? If it does, what are it's priorities (left to right, right to left, precedence, et al)?
-Travis
Short circuiting: the act of saving steps by skipping pointless ones. C/C++, Perl, and I imagine, Java, FORTRAN, Ada, and countless others do this. And example would be...
If Test1 OR Test2 Then DoSomething
The compiler will set it up in such a way that the code will evaluate a little as possible. If it evaluates Test1 and it is true, then it will never evaluate Test2. It doesn't need to, it is an OR. As long as one is true, then all is true.
If this was an AND, then it will not evaluate Test2 if it finds Test1 to be false. Test2 can't save the expression as a whole.
Uses for short circuiting...
You want to execute some block of code if some variable or handle is set to some value, but if that variable or handle is not even defined, evaluation may cause an error.
Open SomeFile
If SomeFileHandle IS NOT NULL AND SomeFileHandle IS NOT EOF Then ReadFile
If you evaluated the EOF on a handle that isn't pointing to anything, you may get an error (not sure if this is true in VB, the language isn't important right now, which is why all this is very base psuedocode). But if the language short circuits, it will only attempt to evaluate the EOF if the handle is not NULL. Now you can nest structures to do the same thing, so if the language doesn't short circuit naturally, it is not a complete loss.
The same is true for auto-increment/decrement operators. I love 'em. VB ain't got 'em.
C++
<PRE>
foo++;
</PRE>
Perl
<PRE>
$foo++; #Even works if foo is set to a alpha character
#or string. Does a ROT-1 (sorta)
</PRE>
VB
<PRE>
intFoo = intFoo + 1
</PRE>
What can you do?
-Travis
Use another language.Quote:
What can you do?
Or break up If's as much as possible. With the ones that are most likely to be false on the very outside.
[Edited by Iain17 on 05-17-2000 at 12:47 PM]
I think you need a transistorised or more advanced IC based short circuit prevention circuitry to prevent VB from short circuiting. Let me know if you want the circuit diagram.:D
I seem to recall reading somewhere that you couldn't rely on the fact of VB evaluating both expressions in an IF statement. There was no mention of why or under what conditions, but it may indicate that VB does a degree of lazy evaluation.
Having said that, if VB *DID* short circuit this should work :
I'll save you the trouble and say that it doesn't, you get "object variable not set" which is correct. If VB did lazy evaluation it would see that the IF will be false and shouldn't evaluate the second part.Code:Dim Test1 As New Form1
Set Test1 = Nothing
If False And Test1.Caption= "foo" Then
MsgBox "Bar!"
End If
An interesting point is that it does this in EXE too. I would have thought an optimising compiler worth it's salt would be able to pick up statements that always evaluate to a particular result and remove them, replacing them with the resultant behaviour. If this was the case then I shouldn't have seen the error message. Anyone have any info on this?
K
Well, this confirms what I suspected. VB doesn't short circuit, or if it does, it is too unreliable. Like I said, you can nest conditionals to get the same effect.
-Travis