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

[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.

[Jeff Johnson [MVP: VB]]

"PagCal" <pa****@runbox.com> wrote in message
news:uE**************@TK2MSFTNGP12.phx.gbl...

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.

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.

[Jay B. Harlow [MVP - Outlook]]

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
Hope this helps
Jay

"PagCal" <pa****@runbox.com> wrote in message
news:uE**************@TK2MSFTNGP12.phx.gbl... 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.

[Herfried K. Wagner [MVP]]

* PagCal <pa****@runbox.com> scripsit:

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

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[SA]

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,

--

Sven
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2l************@uni-berlin.de...

* PagCal <pa****@runbox.com> scripsit:

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

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

* "SA" <in*********@freemail.nl> scripsit:

This is an interesting explanation...

I thought And dubbed as both a binary operator and as a logical operator?

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'.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Cablewizard]

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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2l************@uni-berlin.de...

* "SA" <in*********@freemail.nl> scripsit:

This is an interesting explanation...

I thought And dubbed as both a binary operator and as a logical operator?

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'.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

* "Cablewizard" <Ca*********@Yahoo.com> scripsit:

What ever happened to the BitAnd, BitOr, etc. proposed early on?
They simply don't exist. In other words, 'Or', 'And', ... are bitwise
;-).
Personally, I like the explicitness of differentiating between logical and
bitwise operators.

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

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Tom Shelton]

In article <2l************@uni-berlin.de>, Herfried K. Wagner [MVP] wrote:

* "Cablewizard" <Ca*********@Yahoo.com> scripsit:

What ever happened to the BitAnd, BitOr, etc. proposed early on?

They simply don't exist. In other words, 'Or', 'And', ... are bitwise
;-).

Personally, I like the explicitness of differentiating between logical and
bitwise operators.

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

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 Shelton [MVP]

[Herfried K. Wagner [MVP]]

Tom,

* Tom Shelton <to*@YOUKNOWTHEDRILLmtogden.com> scripsit:

What ever happened to the BitAnd, BitOr, etc. proposed early on?

They simply don't exist. In other words, 'Or', 'And', ... are bitwise
;-).

Personally, I like the explicitness of differentiating between logical and
bitwise operators.

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

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

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

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>