If a() AND b() both ALWAYS execute?

  • Thread starter Thread starter PagCal
  • Start date Start date
P

PagCal

Is this the default and expected behavior for vb.net?

'C' and 'C++' used to skip b() if a() was not true, because there was no
way the IF expression would ever be true.

For example, if you did something like:

If (NOT atEOF()) AND dataValueOK() Then
' process valid data here
ELSE

End if

will blow up in dataValueOK() as it's evaluated EVEN if atEOF() is TRUE.
 
Is this the default and expected behavior for vb.net?

'C' and 'C++' used to skip b() if a() was not true, because there was no
way the IF expression would ever be true.

For example, if you did something like:

If (NOT atEOF()) AND dataValueOK() Then
' process valid data here
ELSE

End if

will blow up in dataValueOK() as it's evaluated EVEN if atEOF() is TRUE.
Click to expand...

Yes, this is the way And works. VB.NET is the first VB to truly support
short-circuiting, which is what you're describing, but it requires new
keywords to do so: AndAlso and OrElse. And and Or still work the way they
always have, i.e., no short-circuiting.
 
PagCal,
Yes, that is the expected behavior for the "And" operator.

If you want to short circuit like C & C++ would, you need to use the
"AndAlso" operator.

Something like:
If (NOT atEOF()) AndAlso dataValueOK() Then
' process valid data here
ELSE

End if
Click to expand...

Hope this helps
Jay
 
* PagCal said:
Is this the default and expected behavior for vb.net?
Click to expand...

Yes. 'And' is a binary operator in VB, and this will cause the binary
operation AND to be performed on the bits of the parts left and right to
the operator. I assume you are looking for the 'AndAlso' operator,
which is a logical operator.
 
This is an interesting explanation...

I thought And dubbed as both a binary operator and as a logical operator?
Which is why I visit this newsgroup...

Thanks,
 
* "SA said:
This is an interesting explanation...

I thought And dubbed as both a binary operator and as a logical operator?
Click to expand...

That's "true".

The binary representation of 'False' is 0000000000000000. By "ANDing"
something with 'False', it will remain false, because there is no bit
set in 'False'. By "ORing" something, the bits will be set if they are
set in the value that is "ORed" with 'False'. The result is treated as
'Boolean' again, so it can be used as condition in an 'If...Then'.
 
What ever happened to the BitAnd, BitOr, etc. proposed early on?
Personally, I like the explicitness of differentiating between logical and
bitwise operators.
If I recall, FoxPro has quite an assortment of BITxxx operators.

Gerald
 
* "Cablewizard said:
What ever happened to the BitAnd, BitOr, etc. proposed early on?
Click to expand...

They simply don't exist. In other words, 'Or', 'And', ... are bitwise
;-).
Personally, I like the explicitness of differentiating between logical and
bitwise operators.
Click to expand...

I would have liked the 'Bit*' operators too, because in general you more
often use a logical 'And' than a bitwise 'And'.
 
They simply don't exist. In other words, 'Or', 'And', ... are bitwise
;-).


I would have liked the 'Bit*' operators too, because in general you more
often use a logical 'And' than a bitwise 'And'.
Click to expand...

It was those damn beta 2 rollbacks! I liked the Bit* stuff as well.
But, to many people complained about "broken" code when upgrading.
 
Tom,

* Tom Shelton said:
It was those damn beta 2 rollbacks! I liked the Bit* stuff as well.
But, to many people complained about "broken" code when upgrading.
Click to expand...

Consequently, a lot of upgraded code uses bitwise operators where using
them doesn't bring a benefit.
 
Back
Top