I am not saying it is stupid, just different. We would have to see how the cmp() function is written, it obviously takes a parameter to use to compare two values. I assume it returns the boolean value of True or False, or 0 or 1 or some other way you keep track of True/False conditions.

It would then be a matter of how the cmp() function handles the parameters and parses out the logic statements. That is if cmp() is a user defined function and not an external one written in another language and linked up at runtime, or imbedded machine code.

But let us just say that it is a user defined function. Excuse my Visual BASIC syntax:

Function cmp(value1 as Integer, opcode as String, value2 as Integer) as Boolean
Dim result as Boolean

result = false ' Just in case the function fouls up

Select Case opcode
Case ">"
If value1 > value2 Then
result = True
Else
result = False
End If
Case "<"
If value1 < value2 Then
result = True
Else
result = False
End If
Case "="
If value1 = value2 Then
result = True
Else
result = False
End If
Case Else
result = False
End Select

cmp = result ' Set the function to the desired result

End Function

In this case, based on what is passed to the function, can return a true or false value. In this way VB can be changed to examine two Intergers via cmp(1,">",2) which would return a Boolean False and cmp(1,"<",2) which would return a Boolean True. Using an OOP design, you could build this function into a class, and overload it so that it can handle Real, Long Integer, and other values by using Overloading. Of course you would have to understand how OOP works to do this, but then cmp(1.1, ">", 1.2) would be valid as much as cmp(1292921, ">", 93919987), but either one would fail on the cmp() function that is written only for Integers and does not handle any sort of OOP design. You would be forced to create multiple copies of this function and name them cmpint(), cmpreal(), complong(), etc.