[RESOLVED] How to convert c language if (exp & 1) { ..... } to vb6

[quickbbbb]

hi~ all

c language

if (exp & 1) 
{ .....  }

vb6

if exp and 1 then

end if
????

[wqweto]

Try

If (Value And 1) <> 0 Then . . .

cheers,
</wqw>

[quickbbbb]

Try

If (Value And 1) <> 0 Then . . .

cheers,
</wqw>

hi ~ wqweto

you mean
if (exp & 1) : vb6 is ---> If (Value And 1) <> 0 Then
if (exp && 1): vb6 also is ---> If (Value And 1) <> 0 Then

[Elroy]

To my way of seeing it:

& is equivalent to AND
| is equivalent to OR

There are a couple of places we run into trouble though. First, we don't really have equivalent operators to && or ||. Instead, we must compare to 0, which accomplishes the same thing:

if (var1 && var2) ...
vs
If (var1 <> 0 And var2 <> 0) Then ...

Secondly, in C/C++, TRUE=1, whereas in VB6, TRUE=-1. And C/C++ programmers are notorious for doing things like:

if (!!var1 + 1 == 2) ...

Basically, that'll be true if var1 is non-zero, but that's just an example. Basically, C/C++ programmers will often use the knowledge that TRUE=1 to do further calculations, which can get us into trouble when translating to VB6.

Also, we don't have a ! operator. We do have a ~ operator though ... it's just NOT.

[Shaggy Hiker]

My C is a bit rusty, but

(exp & 1) != (exp && 1)

in most cases. The first one will evaluate to True or False based on the state of the least significant bit in exp, whereas the second will evaluate to True as long as exp <> 0. Those two aren't all that similar, though they have cases where they overlap.

[Elroy]

(exp & 1) in C/C++ will evaluate to either 1 (TRUE) or 0 (FALSE).

(exp && 1) in C/C++ will also evaluate to either 1 (TRUE) or 0 (FALSE). In fact, you don't need the "&& 1". (exp) in an "if" statement, will also evaluate to a 1 (TRUE) or 0 (FALSE).

And, as you have it, the complete (exp & 1) != (exp && 1) expression will always be FALSE.

[Shaggy Hiker]

I realized that I was ambiguous when I wrote (exp & 1) != (exp && 1). That was meant to be read as "those two expressions are not the same", which is true.

[wqweto]

you mean
if (exp & 1) : vb6 is ---> If (Value And 1) <> 0 Then
if (exp && 1): vb6 also is ---> If (Value And 1) <> 0 Then

No, I don't mean this. Where did I say this?

Both & and && are different operators. There is no equivalent to && in VB6 while & (the bitwise AND) is equivalent to And operator in VB6.

Note that if(exp && 1) { ... is a pointless expression that no one will write in actual code. It can be shortened to the equivalent if (exp) { ... i.e. the && 1 part is redundant.

cheers,
</wqw>

[Elroy]

The && and || operators in C/C++ are quite nice. I wish we had them in VB6. Basically, they reduce both sides to either a 1 or 0 (TRUE or FALSE), and then perform their operation. These are called "boolean" operators (as opposed to bitwise operators). & (in C), | (in C), And (in vb6), Or (in vb6) are all bitwise operators, and it's often important to know this.

For example, in VB6, 1 And 2 And 4 And 8 evaluates to zero. That's sometimes confusing to people, but, if we understand bits, it's obvious.

And, why && would be nice ... in C, 1 && 2 && 4 && 8 evaluates to 1 (True).

[quickbbbb]

I see.

thank for anyone

[Shaggy Hiker]

Another thing that would be nice would be if it short circuited, which Boolean comparisons can do, usually (though it would be entirely possible to implement Boolean operators such that they didn't short circuit). If the truth of the overall expression can be determined before evaluating all parts, then stop evaluating at that point. That feature allows you to avoid some small, though annoying, scenarios.

[quickbbbb]

The && and || operators in C/C++ are quite nice. I wish we had them in VB6.

yes, quite nice.

[Elroy]

Another thing that would be nice would be if it short circuited, which Boolean comparisons can do, usually (though it would be entirely possible to implement Boolean operators such that they didn't short circuit). If the truth of the overall expression can be determined before evaluating all parts, then stop evaluating at that point. That feature allows you to avoid some small, though annoying, scenarios.

Personally, I don't mind the lack of implicit short-circuiting in VB6. It's just one more thing to keep straight with left-to-right or right-to-left, and how parentheses will affect things. But that's just me.

Also, if we want short circuiting, we can just nest several If statements and accomplish the same thing. Also, a Select Case series can often be used for this purpose as well.

[Niya]

For example, in VB6, 1 And 2 And 4 And 8 evaluates to zero. That's sometimes confusing to people, but, if we understand bits, it's obvious.

When I want to be sure I'm performing logical operations instead of bitwise operations in VB6, I'd do something like this:-

CBool(1) And CBool(2) And CBool(4) And CBool(8)

The above correctly evaluates to True.

[2kaud]

In c/c++:

(exp & 1)

will evaluate to a type depending upon the type of exp (eg int if type of exp is int) with a value of either 1 or 0 depending upon the LSB. If this is then used when a type bool is expected (eg in an if condition) then the type is implicitly cast to bool with a value of true or false which is then used.

[wqweto]

In c/c++. . . will evaluate to a type depending upon the type of exp (eg int if type of exp is int) with a value of either 1 or 0 depending upon the LSB.

The more correct reasoning is that the type of expression like (expr1 & expr2) depends on *both* left-side and right-side operand types simultaneously, not on the left-side only.

Otherwise what would be the type of (1 & exp) and can it be different than (exp & 1) type? The real question/problem comes with (exp & 1234) when exp is 8-bit type (like char or uint_8) and the numeric literal does not fit into it.

In VB6 something like (MyByte And 1) is of type Integer (not Byte) because the numeric literal is Integer and because there is no type suffix for Byte it's not possible to force result to be a single Byte while for Long literals as in (MyByte And 1&) the result can be forced to Long.

cheers,
</wqw>

[Elroy]

I like Niya's approach to getting && and || equivalencies:

var1 && var2  ----> Abs(CBool(var1)) And Abs(CBool(var2))
var1 || var2  ----> Abs(CBool(var1)) Or Abs(CBool(var2))
var1 & var2   ----> var1 And var2                                      ' Pretty straightforward.
var1 | var2   ----> var1 Or var2

The Abs() just accounts for the fact that, in C/C++ True=1 and in VB6 True=-1. That will often be not needed, but just done as a precaution, in case subsequent math is done on any result. Doing complex versions of these though would still require that we have the bit-manipulation understandings of what's going on in both C/C++ and VB6.

And yeah, keeping track of the types we're dealing with would also be important in many instances. In VB6, a Boolean is just a special case of an Integer, and will go to an Integer if forced. For instance, Abs(CBool(var1)) returns an Integer.

[Shaggy Hiker]

Personally, I don't mind the lack of implicit short-circuiting in VB6. It's just one more thing to keep straight with left-to-right or right-to-left, and how parentheses will affect things. But that's just me.

Also, if we want short circuiting, we can just nest several If statements and accomplish the same thing. Also, a Select Case series can often be used for this purpose as well.

Personally, I find the lack of short circuiting grating...and I say personally, because I am well aware that my position is utterly absurd. It is VERY unlikely to come up with a scenario where evaluating both parts of a conditional has any measurable performance implication. Evaluating

If False And True Then

just doesn't make any real difference whether you evaluate just the first, or both. So, it's very much a pet peeve. However, peeves DO make good pets. The one place this annoyed me in VB6 was checking whether a DB field was Null or some value. If it was Null, then the check for the value would throw an exception, so it was necessary to nest the two conditionals. This had an impact on performance so utterly tiny that you could only measure it in nanoseconds, but it was not great, and thus did grate.

[Niya]

I think you guys are seriously underestimating the convenience of having short circuiting logical operators. However, it depends on your style of programming. For someone like me who uses objects as data a lot, it's quite important.

Let me give you a contrived example that represent a scenario that comes up often in my own code:-

Private Sub Form_Load()

    Dim r As RestultClass
    
    Set r = GetResult
    
    'Because And is not short ciruited, this would crash the program
    'whenever GetResult returns Nothing
    Do While Not (r Is Nothing) And r.value
        Debug.Print "Loop body executed"
        
        Set r = GetResult
    Loop


End Sub

Private Function GetResult() As RestultClass
    Dim value As Long
    
    value = Random(0, 10)
    
    'Return Nothing sometimes.
    If value = 9 Then Exit Function
    
    Set GetResult = New RestultClass
        
    GetResult.value = CBool(value)
    
    

End Function

Private Function Random(ByVal Min As Long, ByVal Max As Long) As Long
    Randomize Timer
    Random = Int((Max - Min + 1) * Rnd + Min)
End Function

The loop in the above code is flawed because GetResults can return Nothing sometimes. However, when it does, the right operand of the And expression is still evaluated and this operand expects a valid object reference. If AND was short circuited then it would work correctly. To get around the lack of short circuit evaluation here you'd have to do either this:-

    Dim r As RestultClass
    
    Set r = GetResult
    
    Do
        If r Is Nothing Then
            Exit Do
        Else
            If Not r.value Then Exit Do
        End If
        
        Debug.Print "Loop body executed"
        
        Set r = GetResult
    Loop

The above I find personally distasteful and ugly.

You can also do this:-

    Dim r As RestultClass
    
    Set r = GetResult
    
    Do While Not (r Is Nothing)
        
        If Not r.value Then Exit Do
        
        Debug.Print "Loop body executed"
        
        Set r = GetResult
    Loop

It's cleaner than the one previously but still not as clean as having it all on one line in the While clause itself.

[Elroy]

Niya, you don't need the "else", and this is a case where I'd use single line "if" statements. Here's how I'd write that code:

    Do
        If r Is Nothing Then Exit Do
        If Not r.Value Then Exit Do

        Debug.Print "Loop body executed"

        Set r = GetResult
    Loop

Personally, I don't really see any problems with that. But, to each their own.

p.s., I often run into precisely that problem when doing a Seek on an indexed recordset. I've got to check NoMatch before I check something in the recordset, and the above is pretty much exactly how I do it.

[Niya]

Yea that works too.

Well I guess it's a matter of taste in the end. I personally prefer all the conditions for the loop's execution be in the Do statement itself and not the loop body. I find it more readable. There is also another thing that bothers me about this. Notice that the conditions you're testing for is reversed. In the Do statement, you're testing for True but if you use If statements, you test for False. That extra cognitive load can become quite annoying if the conditions aren't straightforward. You have to go from thinking in terms of "I want this loop to run while...." to thinking in terms of "I want this loop to end when...".

This is just my personal feelings on the matter. So to each his own like you said.

Also, it's not that big a deal since you often end up having to put conditionals in the loop body anyway if the actions you must take become more complicated than simply exiting the loop.

[Niya]

Just a minor comment on this:-

Niya, you don't need the "else", and this is a case where I'd use single line "if" statements.

You stumbled onto one of my weaknesses. I'm not good at formulating "fall through" logic. I think in very explicit terms and my code reflects that mental picture. It sometimes leads to a more verbose way of doing things.

[Shaggy Hiker]

It both supports my position: Short circuiting would be nice, but not having it causes only minor inconveniences/inefficiencies.

I want the short circuiting, I just realize that it doesn't REALLY matter all that much.

[Niya]

It both supports my position: Short circuiting would be nice, but not having it causes only minor inconveniences/inefficiencies.

I want the short circuiting, I just realize that it doesn't REALLY matter all that much.

The real problem comes when you start switching between VB6 and another language that has short circuiting. You tend to make mistakes if you're on auto-pilot writing VB6 code because your default "mental mode" is to assume short circuiting. It came up when I was writing this. I had to put extra effort to be very careful whenever I was writing conditional code because I spent years getting used to the short-circuiting behavior of AndAlso and OrElse in VB.Net.

[Shaggy Hiker]

That situation exists when switching between any two languages, to a greater or lesser extent.

[Niya]

That situation exists when switching between any two languages, to a greater or lesser extent.

Not really in this case. If I were switching between say VB.Net and C# or C++ it doesn't feel the same because they are all consistent in this case. They give you a choice. For me, I always short circuit so I can pretty much write conditional loops the same way in all these languages. VB6 doesn't give you a choice so I break from what I'm accustomed to so I can't auto-pilot it. I have to force myself to remember that I can't short-circuit in VB6 otherwise I'd write incorrect code due to my practiced tendencies.

It's not a complaint against VB6, it's just a matter of me being used to the more common thing which is to have a choice.

Right now I'm preparing myself for a future in Python so I'm in the process of familiarizing myself with the language. There are things I absolutely hate about it but what I find interesting is how much it has in common all modern languages including short-circuit evaluation.

[Shaggy Hiker]

Right now I'm preparing myself for a future in Python so I'm in the process of familiarizing myself with the language.

Well, we're off topic, so I'll only say that I was preparing myself for a future in a python, too, but all we found were a couple cottonmouths and a walking catfish.

[Niya]

lol...