[RESOLVED] Why are VB6 IF-expressions so inefficient?

[dreammanor]

When the VB IF statement performs an "And" condition check, it needs to check (execute) each sub-condition expression before determining whether the condition is true. But in other languages, if the first sub-condition does not hold, the remaining condition judgment will not be executed. Why is the condition judgment of VB6 so inefficient?

Private Sub TestVBConditonExpression()
    
    If Condition_01() And Condition_02() And Condition_03() And Condition_04() Then
        MsgBox "Conditon succeeded !"
    Else
        MsgBox "Conditon failed !"
    End If
    
End Sub

Private Function Condition_01() As Boolean
    MsgBox "Condition 01 -- Failed"
End Function

Private Function Condition_02() As Boolean
    MsgBox "Condition 02 -- Failed"
End Function

Private Function Condition_03() As Boolean
    MsgBox "Condition 03 -- Failed"
End Function

Private Function Condition_04() As Boolean
    MsgBox "Condition 04 -- Failed"
End Function

Private Sub Form_Click()
    TestVBConditonExpression
End Sub

[qvb6]

The answer is because VB And/Or/Not are always bitwise operators. VB needs to figure out the full expression before deciding the outcome.

[qvb6]

See also:

Short-circuit evaluation with Select Case
http://www.devx.com/vb2themax/Tip/18263

[Magic Ink]

I have never really thought of 'if … thens' being especially inefficient, surely it is down to the work which has to done to; 1. establish the value of conditions and 2. to compare them. Obviously if we are calculating the conditions on the fly (eg. from called functions as in your example) and we have many conditions the process will be slower.
VB6's compile does not shortcut logical compares and calculates every condition on a given line of code every time, however that can be mostly overcome if 'if … thens' are nested as in;

eg.

If Condition_01() then
   if Condition_02() then
       If Condition_03() then
           if  Condition_04() Then
               Success=True
           end if
       end if
    end if
end if

I feel that I'm teaching you to suck eggs here, but may be it is all new to you, enjoy...

[baka]

even so, the cpu nowadays are so fast that in most cases it doesnt matter.
but I get it, if speed is important and the function is complex with lots of if's that require millions of checks, it could make it slow.
fortunately, today, what takes time is mostly rendering and 3d effects, and for that we have engines that do the job for us.

[techgnome]

I don't know that I'd call it ineeficient... maybe less than desirable depending on what your desired outcome is perhaps...
The root of the reason is that the syntax tree looks at it like this:
if <expression> then
Now, that <expression> can be a simple one, or a complex one, comprised of ands, ors, xors, or even nots... but it has to boil down to a single expression value first... and that means running any and all function call within it first before dermining if it can continue or not.


-tg

[PlausiblyDamp]

even so, the cpu nowadays are so fast that in most cases it doesnt matter.
but I get it, if speed is important and the function is complex with lots of if's that require millions of checks, it could make it slow.
fortunately, today, what takes time is mostly rendering and 3d effects, and for that we have engines that do the job for us.

The big problem comes if some of the functions being executed are complex or otherwise slow (file i/o etc), evaluating every statement can lead to a lot of overheads that nearly any other language would have avoided by short circuiting the evaluation.

[Shaggy Hiker]

Another issue would be if part of the condition won't evaluate correctly if the first part is a certain way. For example, checking whether a field is Null, and doing something with it if it isn't. With a short-circuiting operator, that can be one line.

I don't know why they did it this way, but it may have been a form of efficiency, at the time, or a failure of imagination. VB.NET added the AndAlso and OrElse operators for short circuiting. Perhaps they could only think of AndAnd at the time (to match the && of C), or perhaps they were noting that one operator could serve for logical and bitwise operations and thought that efficient. Whatever it was, they apparently recognized the error of their ways, but not in time to help VB6.

[dilettante]

You can always hand-code things the long way. Shortcutted expression evaluation is just syntactic sugar.

[shagratt]

When the VB IF statement performs an "And" condition check, it needs to check (execute) each sub-condition expression before determining whether the condition is true. But in other languages, if the first sub-condition does not hold, the remaining condition judgment will not be executed. Why is the condition judgment of VB6 so inefficient?
[/code]

Just my guessing but I think the devs of vb6 have something like this in mind when creating the language:

If (PrepareScreen() Or PreparePrinter()) Then
    MsgBox "Errors Found. Please check log."
End If

if the IF exit on the first function then PreparePrinter() is never executed and that may not be the desired result.
Of course if no function is involved I have no clue why. The only fix is to do nested if's

[baka]

The big problem comes if some of the functions being executed are complex or otherwise slow (file i/o etc), evaluating every statement can lead to a lot of overheads that nearly any other language would have avoided by short circuiting the evaluation.

if this is the case we use multiple if's.
usually we use and/or when checking numbers or comparing two binary/strings, not calling functions to return something, like reading from file.
I have never used something like
if x > 5 and therescrapinsideafile() then
usually I do
if x > 5 then if therescrapinsideafile() then

so in the end its not about the if's but how you make your code.
when I do something I try to make as much "pre-calculation" possible before starting any command.
like, in my game, I have a program that creates a database with specific data, ready to be examined in specific ways,
so, in-game I only use the fastest possible function to get what it require.

reading from file takes so much more time to do than a bunch of if's that is almost nonexistent.
that is why we need to brainstorm first, what is the best way to do this, instead of just making code On the fly.

[Elroy]

If Condition_01() Then If Condition_02() Then If Condition_03() Then If Condition_04() Then

VB6 has never done implicit shortcutting. However, you can easily explicitly do it if you so choose. In the above, you'd try and put the conditions most likely to be false first.

[dreammanor]

Thank you all, qvb6,Magic Ink, baka, techgnome, PlausiblyDamp, Shaggy Hiker, dilettante, shagratt and Elroy.

The problem is that VB6 IF-expressions are not only inefficient, but they also affect logical judgments when the logical conditions/functions will change global variables. E.g:

If Step_01() And Step_02() And Step_03() And Step_04() Then
        MsgBox "All steps have been successfully performed !"
    Else
        MsgBox "Some steps failed !"
    End If

Or

If Solution_01() Or Solution_02() Or Solution_03() Or Solution_04() Then
        MsgBox "A solution was successfully executed !"
    Else
        MsgBox "All solutions failed !"
    End If

In addition, baka and Elroy's solution is only applicable to "single line of code", the following multiple lines of code display malformed:

Private Sub TestVBConditonExpression_02()
    
    If Condition_01() Then If Condition_02() Then If Condition_03() Then
        MsgBox "Conditon-01 succeeded !"
    ElseIf Condition_04() Or Conditon_05() Or Conditon_06 Then
        MsgBox "Conditon-02 succeeded !"
    Elseif Conditon_07() then if Condtion_08() then
        MsgBox "Conditon-03 succeeded !"
    Else
        MsgBox "Conditon failed !"
    End If
    
End Sub

[ChrisE]

get the conditon of Day time

Private Sub Command1_Click()
      Label1.Caption = GetTagesZeit(Now)
End Sub


Private Function GetTagesZeit(Uhrzeit As Date) As String
      Select Case Format(Uhrzeit, "hh:nn:ss")
         Case "06:00:00" To "11:59:59"
            GetTagesZeit = "Morning"
         Case "12:00:00" To "15:59:59"
           GetTagesZeit = "Noon"
         Case "16:00:00" To "17:59:59"
            GetTagesZeit = "Afternoon"
         Case "18:00:00" To "21:59:59"
            GetTagesZeit = "Evening"
         Case Else
      End Select
End Function

[dreammanor]

get the conditon of Day time

Private Sub Command1_Click()
      Label1.Caption = GetTagesZeit(Now)
End Sub


Private Function GetTagesZeit(Uhrzeit As Date) As String
      Select Case Format(Uhrzeit, "hh:nn:ss")
         Case "06:00:00" To "11:59:59"
            GetTagesZeit = "Morning"
         Case "12:00:00" To "15:59:59"
           GetTagesZeit = "Noon"
         Case "16:00:00" To "17:59:59"
            GetTagesZeit = "Afternoon"
         Case "18:00:00" To "21:59:59"
            GetTagesZeit = "Evening"
         Case Else
      End Select
End Function

Hi ChrisE, Select statements can only implement "condition evaluation short-circuit" under certain conditions, but this may cause logical confusion or errors. E.g:

Select Case True
    Case Not Condition_01(), Not Condition_02(), Not Condition_03(), Not Condition_04()
        MsgBox "Conditon failed !"
    Case Else
        MsgBox "Conditon succeeded !"
    End Select

[dreammanor]

I have never really thought of 'if … thens' being especially inefficient, surely it is down to the work which has to done to; 1. establish the value of conditions and 2. to compare them. Obviously if we are calculating the conditions on the fly (eg. from called functions as in your example) and we have many conditions the process will be slower.
VB6's compile does not shortcut logical compares and calculates every condition on a given line of code every time, however that can be mostly overcome if 'if … thens' are nested as in;

eg.

If Condition_01() then
   if Condition_02() then
       If Condition_03() then
           if  Condition_04() Then
               Success=True
           end if
       end if
    end if
end if

I feel that I'm teaching you to suck eggs here, but may be it is all new to you, enjoy...

Hi Magic Ink, how to deal with Else statement? E.g:

    If Condition_01() And Condition_02() And Condition_03() And Condition_04() Then
        MsgBox "Conditon-01 succeeded !"
    ElseIf Condition_05() And Condition_06() And Condition_07() And Condition_08() Then
        MsgBox "Conditon-02 succeeded !"
    Else
        MsgBox "Conditon failed !"
    End If

[DataMiser]

To deal with the elseif you could use another if block as with the first part as that is what an elseif is.

[dreammanor]

To deal with the elseif you could use another if block as with the first part as that is what an elseif is.

Yes, I need to write it like this:

    Dim Success01 As Boolean
    Dim Success02 As Boolean
    Dim Success03 As Boolean
      
    If Condition_01() Then
        If Condition_02() Then
            If Condition_03() Then
                If Condition_04() Then
                    Success01 = True
                End If
            End If
         End If
    End If
    
    If Success01 = False Then
        If Condition_05() Then
            If Condition_06() Then
                If Condition_07() Then
                    If Condition_08() Then
                        Success02 = True
                    End If
                End If
             End If
        End If
    End If
    
    If Success01 = False And Success02 = False Then
        Success03 = True
    End If

    If Success01 = True Then
        DoSomething01
    ElseIf Success02 = True Then
        DoSomething02
    ElseIf Success03 = True Then
        DoSomething03
    End If

[npac4o]

The modern languages are doing the same under the hood:

bRes = Condition1()
if bRes = False then Goto *failed*
bRes = Condition2()
if bRes = False then Goto *failed*

This is C# code:

using System;

class Program
{
	static void Main()
	{
		if (Condition1() && Condition2() && Condition3() && Condition4())
		{
			Console.WriteLine("All done!");
		}
        else 
		{			
			Console.WriteLine("Something failed");
		}
	}

	private static bool Condition1()
    {
		Console.WriteLine("Fire Condition1");
		return true;
    }

	private static bool Condition2()
	{
		Console.WriteLine("Fire Condition2");
		return true;
	}

	private static bool Condition3()
	{
		Console.WriteLine("Fire Condition3");
		return true;
	}

	private static bool Condition4()
	{
		Console.WriteLine("Fire Condition4");
		return true;
	}


}

and this is the IL code:

.method private hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       63 (0x3f)
  .maxstack  1
  .locals init (bool V_0)
  IL_0000:  nop
  IL_0001:  call       bool Program::Condition1()
  IL_0006:  brfalse.s  IL_001d
  IL_0008:  call       bool Program::Condition2()
  IL_000d:  brfalse.s  IL_001d
  IL_000f:  call       bool Program::Condition3()
  IL_0014:  brfalse.s  IL_001d
  IL_0016:  call       bool Program::Condition4()
  IL_001b:  br.s       IL_001e
  IL_001d:  ldc.i4.0
  IL_001e:  stloc.0
  IL_001f:  ldloc.0
  IL_0020:  brfalse.s  IL_0031
  IL_0022:  nop
  IL_0023:  ldstr      "All done!"
  IL_0028:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_002d:  nop
  IL_002e:  nop
  IL_002f:  br.s       IL_003e
  IL_0031:  nop
  IL_0032:  ldstr      "Something failed"
  IL_0037:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_003c:  nop
  IL_003d:  nop
  IL_003e:  ret
} // end of method Program::Main

So, it's up to you to write better condition checks. This would fit in most cases:

If Condition_01() then
   if Condition_02() then
       If Condition_03() then
           if  Condition_04() Then
               Success=True
           end if
       end if
    end if
end if

P.S. This is what VB6 is doing, the same as using AND (&):

.method private hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       57 (0x39)
  .maxstack  2
  .locals init (bool V_0)
  IL_0000:  nop
  IL_0001:  call       bool Program::Condition1()
  IL_0006:  call       bool Program::Condition2()
  IL_000b:  and
  IL_000c:  call       bool Program::Condition3()
  IL_0011:  and
  IL_0012:  call       bool Program::Condition4()
  IL_0017:  and
  IL_0018:  stloc.0
  IL_0019:  ldloc.0
  IL_001a:  brfalse.s  IL_002b
  IL_001c:  nop
  IL_001d:  ldstr      "All done!"
  IL_0022:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0027:  nop
  IL_0028:  nop
  IL_0029:  br.s       IL_0038
  IL_002b:  nop
  IL_002c:  ldstr      "Something failed"
  IL_0031:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0036:  nop
  IL_0037:  nop
  IL_0038:  ret
} // end of method Program::Main

[qvb6]

npac4o: I think you are misinterpreting C# disassembly. It's actually short-circuiting, while VB6/VB.Net don't, unless you use AndAlso/OrElse in VB.Net.

Also, I posted this on another thread, but it's worth repeating here. Pascal has similar operators(And/Or/Not), but they manged to accomplish both Logical(&&/AndAlso), and Bitwise operations without needing to add AndAlso/OrElse or any other operator. In Pascal, if the two operands are of type Boolean, then a logical operation is done with short-circuiting, but if both operands are numbers, then a bitwise operation is done instead. So there is no need for extra keywords. So for example:

Result = Bool1 And Bool2        ' <--- Logical with short-circuiting
Result = Number1 And Number2    ' <--- Bitwise, because both are numbers
Result = Number1 And Bool2      ' <--- Type mismatch, mixing Boolean and non-Boolean
Result = Bool1 And Number2      ' <--- Type mismatch, mixing Boolean and non-Boolean
Result = Not Bool1              ' <--- Logical Not
Result = Not Number1            ' <--- Bitwise Not

Also, I am not sure, but in Pascal, one could change this behavior by using #pragma(Similar to Option Statement in VB6). We could add "Option ShortCircuit On" to control this feature in a future VB7.

[Shaggy Hiker]

That example for Pascal, while quite possibly correct (I've never written in Pascal), is showing a deficiency of Pascal, not an advantage. One could say that And and Or in VB.NET work the way you have described when the operands are integers, but when the operands are Booleans, then VB.NET does not short circuit. You have to use AndAlso or OrElse to short circuit. What Pascal is doing is assuming that you WANT to short circuit if the operands are Booleans, whereas VB6 and VB.NET are both assuming that you do NOT want to short circuit if the operands are Booleans.

While it is far more likely to want to short circuit when using Boolean operands, so the Pascal approach is more often going to be best, there are times when you must not short circuit. The example would be where bother operands result from method calls, both of which should happen, regardless of the outcome of the conditional. It's programming with side effects, which is generally not a good idea, but there are times when it can be quite efficient. The other way to write it would be to write both methods separately, populating a pair of local Boolean variables, then write the conditional to compare the two:

Dim bool1 = SomeFunc()
Dim bool2 = SomeOtherFunc()

If bool1 And bool2 Then

'Which could be written:

if SomeFunc() And SomeOtherFunc() Then

That second option isn't available in Pascal, from your description. It's a pretty rare case, though, so perhaps Pascal is doing it better. One can argue that you can ALWAYS do this, and the only cost is the trivial cost of having two local variables, or more if there are more elements in the conditional. To be sure, in VB.NET, you use AndAlso FAR more than you use And, so making it the default does make sense. By providing two operators, you just get the option of which you use, so you can have it both ways. Whether that is better or not is a matter of opinion. Either way, the choice that was made for classic VB, probably from before the V was added to B, was not the best one.

[dilettante]

I suspect the "decision" was made in Microsoft Basic long before it had boolean functions as a language construct.

[npac4o]

npac4o: I think you are misinterpreting C# disassembly. It's actually short-circuiting, while VB6/VB.Net don't, unless you use AndAlso/OrElse in VB.Net.

Which was exactly my idea - to show how C# and VB.NET are doing the short-circuiting. I thought it's obvious.

The first IL code shows what is happening when && for C# and AndAlso for VB.NET is used. It checks if for False after each condition and skip to the result if it is.

The second IL code is with & and AND - it is checking all conditions, no matter of the results. This is exactly how VB6 is working - no short-circuiting.

I really thought that it's obvious...

[wqweto]

The second IL code is with & and AND - it is checking all conditions, no matter of the results.

There is no code with & and AND in your post.

Are you trying to tell everyone here it's obvious how to reconstruct the original source code in your mind by looking at the generated IL? In a forum where most people don't touch .Net platform at all?

cheers,
</wqw>

[npac4o]

Sorry, Владо, my bad.

The second IL code was added on the fly, just for comparison to the short-circuiting procedure.

It would be the same C# code but using & instead of &&:

C#
if (Condition1() & Condition2() & Condition3() & Condition4()) {...}

VB.NET
If Condition1() And Condition2() And Condition3() And Condition4() Then...End If

VB6
If Condition1 And Condition2 And Condition3 And Condition4 Then...End If

The code snippets above always evaluate all conditions.

The following code is short-circuiting the operation:

C#
if (Condition1() && Condition2() && Condition3() && Condition4()) {...}

VB.NET
If Condition1() AndAlso Condition2() AndAlso Condition3() AndAlso Condition4() Then...End If

A rough translation of the IL code in the previous post to VB6 would be something like that:

    bRes = Condition1
    If bRes = False Then GoTo Results
    bRes = Condition2
    If bRes = False Then GoTo Results
    bRes = Condition3
    If bRes = False Then GoTo Results
    bRes = Condition4
    
Results:
    If bRes = False Then GoTo Failed
    ' Success, do something
    Goto Finish
Failed:
    ' Failed, do something else
Finish:
    ' do the rest

I hope that this would show that the short-circuiting is not a *magic* that modern languages are using, just a few more conditions.

[Schmidt]

Yes, I need to write it like this:

    Dim Success01 As Boolean
    Dim Success02 As Boolean
    Dim Success03 As Boolean
      
    If Condition_01() Then
        If Condition_02() Then
            If Condition_03() Then
                If Condition_04() Then
                    Success01 = True
                End If
            End If
         End If
    End If
    
    If Success01 = False Then
        If Condition_05() Then
            If Condition_06() Then
                If Condition_07() Then
                    If Condition_08() Then
                        Success02 = True
                    End If
                End If
             End If
        End If
    End If
    
    If Success01 = False And Success02 = False Then
        Success03 = True
    End If

    If Success01 = True Then
        DoSomething01
    ElseIf Success02 = True Then
        DoSomething02
    ElseIf Success03 = True Then
        DoSomething03
    End If

Nah, far too "wordy" ... a single (Enum-like) State-Variable would be sufficient.

Also note, that typing " Then If " (in case such a construction is given on a single VB6-Line),
requires the same amount ot "chars to type" as " AndAlso ".

With that in mind (along with our "single State-Variable"), we can write this -
like in the Then_If_Plus_State_ForShortCircuiting() routine below:

Const Msg_State1 = "Cond 1-3 were all true (no need to check Cond 4-6)"
Const Msg_State2 = "Cond 4-6 were all true (after at least 1 of Cond 1-3 was false)"
Const Msg_State0 = "No cigar! (at least 1 in each of the 2 combining-conditions were false)"

Private Sub Form_Load()
'  Debug.Print: NormalImplementation_NoShortCircuiting
  Debug.Print: Then_If_Plus_State_ForShortCircuiting
End Sub

Sub NormalImplementation_NoShortCircuiting()
  If C(1, 0) And C(2) And C(3) Then
    MsgBox Msg_State1
  ElseIf C(4, 0) And C(5) And C(6) Then
    MsgBox Msg_State2
  Else
    MsgBox Msg_State0
  End If
End Sub

Sub Then_If_Plus_State_ForShortCircuiting()
 Dim State As Long
  If State = 0 Then If C(1, 0) Then If C(2) Then If C(3) Then State = 1
  If State = 0 Then If C(4, 0) Then If C(5) Then If C(6) Then State = 2
  
  Select Case State
    Case 1: MsgBox Msg_State1
    Case 2: MsgBox Msg_State2
    Case 0: MsgBox Msg_State0
  End Select
End Sub

Function C(Idx, Optional ByVal Ret& = -1) As Boolean
  C = Ret '<- to make it return False, pass Ret with 0 from our test-code
  Debug.Print "C(" & Idx & ") call returned: " & C
End Function

I've marked the "AndAlso" like elements in blue above
(which allow to incorporate the previous State into the expression).

HTH

Olaf

[npac4o]

Option Explicit

Private Sub Form_Load()
Dim x As Integer: x = 5
Dim y As Integer: y = 10
    
    Debug.Print IsTrue(x = y / 2, x < y, Not ReturnFalse, ReturnTrue)
    Debug.Print IsTrue(x = 5, y = 10, ReturnFalse = False, ReturnTrue = True)
    Debug.Print IsTrue((5 * 5 = 20 + 5), True, Not False)
    Debug.Print IsTrue((5 * 5 = 20 + 5), True, False = False)
    Debug.Print IsTrue((5 * 5 = 20 + 5), True, False)
    Debug.Print IsTrue((5 * 5 = 20 + 5), ReturnFalse = Not ReturnTrue, True)
    
    Debug.Print IsTrue(ReturnTen < 10)
    Debug.Print IsTrue(ReturnTen = 10)
    Debug.Print IsTrue(ReturnTen > 10)
    
    Debug.Print IsTrue(ReturnAbc = "Abc")
    Debug.Print IsTrue(Len(ReturnAbc) = 3)
    Debug.Print IsTrue(ReturnAbc, ReturnTen)
    
End Sub

Private Function IsTrue(ParamArray aParam() As Variant) As Boolean
    Dim lCount As Long, lItem As Long

    IsTrue = True
    
    If UBound(aParam) >= 0 Then
        lCount = UBound(aParam)

        For lItem = 0 To lCount
            If VarType(aParam(lItem)) = vbBoolean Then
                If aParam(lItem) = False Then
                    IsTrue = False
                    GoTo Finish
                End If

            Else
                IsTrue = False
                GoTo Finish
            End If

        Next
    End If

Finish:
    
End Function

Private Function ReturnTrue() As Boolean
    ReturnTrue = True
End Function

Private Function ReturnFalse() As Boolean
    ReturnFalse = False
End Function

Private Function ReturnTen() As Integer
    ReturnTen = 10
End Function

Private Function ReturnAbc() As String
    ReturnAbc = "Abc"
End Function

[Schmidt]

Private Function IsTrue(ParamArray aParam() As Variant) As Boolean
...

Not sure, what this is supposed to help with...
but short-circuiting it does not...

Olaf

[npac4o]

Are sure you?

Private Sub Form_Load()
     Call IsTrue(1 = 1, 2 = 2, 3 = 6, 4 = 4)   
End Sub

Private Function IsTrue(ParamArray aParam() As Variant) As Boolean
    Dim lCount As Long, lItem As Long

    IsTrue = True
    
    If UBound(aParam) >= 0 Then
        lCount = UBound(aParam)

        For lItem = 0 To lCount
            If VarType(aParam(lItem)) = vbBoolean Then
                If aParam(lItem) = False Then
                    IsTrue = False
                    GoTo Finish
                End If

            Else
                IsTrue = False
                GoTo Finish
            End If
            Debug.Print lItem
        Next
    End If

Finish:
    
End Function

Output:
0
1

[Schmidt]

Are sure you?

Being sure, that I am...

Private Sub Form_Load()
    Call IsTrue(C(1), C(2), C(3, 0), C(4))
End Sub
 
'less "noisy" re-write of your IsTrue-function (fully compatible to the previous one)
Private Function IsTrue(ParamArray P() As Variant) As Boolean
    Dim i As Long
    For i = 0 To UBound(P)
        If VarType(P(i)) <> vbBoolean Then Exit Function 'return false
        If Not P(i) Then Exit Function 'return false
        Debug.Print i
    Next
    IsTrue = i > 0 'make sure, to return false in case of no Params
End Function
 
Function C(Idx, Optional ByVal Ret& = -1) As Boolean
    C = Ret '<- to make it return False, pass Ret with 0 from our test-code
    Debug.Print "C(" & Idx & ") call returned: " & C
End Function

Output:

C(1) call returned: True
C(2) call returned: True
C(3) call returned: False
C(4) call returned: True
 0 
 1

[npac4o]

Hm, yep. It short-circuiting not... At least it was looking good

[dreammanor]

Very valuable discussion, thank you, Olaf, thank you, npac4o, and thank you all.

[crapapelata]

Sorry for reviving a six years old thread.

I'm aware of this method to achieve short-circuit-evaluation in VB6, the only one native AFAIK.

Below a simple example
N.B. if the condition 1 / 0 were evaluated, it would raise an exception

'given: A = (1=1) : B = (1 / 0)
'this outs (A OR B) with short-circuit-evaluation:
Select Case True
    Case 1 = 1, 1 / 0
        Msgbox "A Or B is True (since A is already True without even having to consider B)"
    Case Else
        Msgbox "A Or B is False"
End Select

'given: A = (1=2) : B = (1 / 0)
'this outs (A AND B) with short-circuit-evaluation:
Select Case False
    Case 1 = 2, 1 / 0
        Msgbox "A And B is False (since A is already False without even having to consider B)"
    Case Else
        Msgbox "A And B is True"
End Select

Regards

[wqweto]

Sorry for reviving a six years old thread.

I'm aware of this method to achieve short-circuit-evaluation in VB6, the only one native AFAIK.

Below a simple example
N.B. if the condition 1 / 0 were evaluated, it would raise an exception

'given: A = (1=1) : B = (1 / 0)
'this outs (A OR B) with short-circuit-evaluation:
Select Case True
    Case 1 = 1, 1 / 0
        Msgbox "A Or B is True (since A is already True without even having to consider B)"
    Case Else
        Msgbox "A Or B is False"
End Select

'given: A = (1=2) : B = (1 / 0)
'this outs (A AND B) with short-circuit-evaluation:
Select Case False
    Case 1 = 2, 1 / 0
        Msgbox "A And B is False (since A is already False without even having to consider B)"
    Case Else
        Msgbox "A And B is True"
End Select

Regards

This is a good snippet now as the 3-rd post in this thread contains a dead link already.

cheers,
</wqw>