AndAlso

  • Thread starter Thread starter Al G
  • Start date Start date
A

Al G

Ok, so I've started to use it, and it is quicker.

Now, why is it that "AND" doesn't already work this way?


Al G
 
Ok, so I've started to use it, and it is quicker.

Now, why is it that "AND" doesn't already work this way?
Click to expand...

Opinion alert!
From what I can tell, the primary reason to use andalso is not to
Click to expand...
speed up your code, although that can be a pleasant side effect. I
only use it when the second operand in the logical expression would
throw an exception if the first operand is false. So to prevent the
second operand from even being evaluated when the first operand is
false, I use the andalso. Same for orelse.
 
Zack read the link i provided above

For logical operators i always use OrElse , AndAlso

if i need a bitwise comparisation i use Or , And
 
Michel Posseth said:
read this and you know it all
http://www.panopticoncentral.net/articles/919.aspx ( and maybe more :-)

hth

Michel
Click to expand...

Thanks Michel, good article. Short cutting is a good term, and in
the situation:
If (Not x Is Nothing) And (x.y = 10) Then
...
End If

Short Cutting prevents an exception from being thrown by the second half
when x does equal nothing.

However, in the situation:
If Foo() and Bar() then
...
End if

Doesn't Foo() have to evaluate to a boolean value?
If Foo() returned an integer or something the If would never work, would it?
If Foo() evaluates to a Boolean, why ever check Bar()?

I guess I'm not seeing the situation where you want it to work like and/or
does now.

The article talks about not knowing the "Result type" of Foo() and Bar(),
and I'm sure that
is part of what I'm missing.

Al G
 
But ...

If Foo() returns an integer than it is evaluatable as a boolean.

A value of 0 will evaluate to False - A value of anything elese will
evaluate to True (or, more correctly, Not False).

If Foo() And Bar()

will check both expressions, whereas:

If Foo() AndAlso Bar()

will only check Bar() if Foo() evaluates to True.
 
Stephany Young said:
But ...

If Foo() returns an integer than it is evaluatable as a boolean.

A value of 0 will evaluate to False - A value of anything elese will
evaluate to True (or, more correctly, Not False).

If Foo() And Bar()

will check both expressions, whereas:

If Foo() AndAlso Bar()

will only check Bar() if Foo() evaluates to True.
Click to expand...
Ok, but if Foo() evaluates to a boolean value, as suggested by the
syntax,
why check Bar(). In other words, why would you want to do it the old way?

Al G
 
Al,

It was an in my eyes a stupid decision for not breaking the VB classic code
probably because of the until 2005 strong VB6 lobby not to change the VB6
code.

Cor
 
Al G said:
Ok, but if Foo() evaluates to a boolean value, as suggested by the
syntax,
why check Bar(). In other words, why would you want to do it the old
way?
Click to expand...

.... you'd want to do it if it is a requirement that both parts get
evaluated/called. In other words, if you would have written

\\\
Dim Val1 As Boolean = Function1()
Dim Val2 As Boolean = Function2()
If Val1 AndAlso Val2 then
...
End If
///

you could have written

\\\
If Function1() And Function2() Then
...
End If
///

too.
 
Michel Posseth said:
For logical operators i always use OrElse , AndAlso

if i need a bitwise comparisation i use Or , And
Click to expand...

"Logical" doesn't mean "short circuiting". 'Or' and 'And' are logical and
bitwise, depending on the situation.
 
Al G <agerhart2 said:
Ok, so I've started to use it, and it is quicker.

Now, why is it that "AND" doesn't already work this way?
Click to expand...



IMHO...

MS did a pretty good job of designing VB up through VB 6.
However, they didn't do a perfect job. That's understandable.
They're a bunch of humans and humans always make a few mistakes.
And it's always easier to see the mistakes with the benefit of
hindsight.

With VB.Net, in order to move the language forward, they really
needed to make a major overhaul. This time, instead of doing a
pretty good job, they did, again IMHO, a fantastic job. VB.Net is
so much better in so many ways than VB6 that it's simply mind
boggling. Compare Try...Catch...Finally to OnError...Resume Next,
for example.

Of course, when they designed VB.Net, they had not been elevated
to god status, (articles in The Onion, notwithstanding). They
were still a bunch of error prone humans. WRT And and Or, they
screwed up. They should have fixed those operators to work the
way they do in other languages, including short circuiting. This
was probably one of their biggest mistakes. Instead of adding
AndAlso and OrElse (which IMHO are too verbose), they should have
added the BitAnd and BitOr operators like Michel Posseth's
article mentioned they had considered. They changed many other
behaviours so I'm not sure why they got cold feet on this one.
 
In the cases of AndAlso vs. And and OrElse vs. Or, the issue MS had to
struggle with was that VB 6 and earlier didn't short circuit the conditional
evaluation and a lot of existing code depended on this behavior. Even C and
C++ have non-short circuit versions of And ( & ) and Or ( | ) - they're
simply not used much. Changing the behavior of And and Or would have caused
nearly 100% of all VB 6 programs to break upon porting to VB.Net (any
version).

Mike Ober
 
Michael D. Ober said:
In the cases of AndAlso vs. And and OrElse vs. Or, the issue MS had to
struggle with was that VB 6 and earlier didn't short circuit the conditional
evaluation and a lot of existing code depended on this behavior.
Click to expand...



They had that same issue with many other features and that didn't
stop them from changing the language.

Alot of people complained about the long list of changes that
were made. Not me. I feel that "we did it wrong" is not a good
reason to continue doing it wrong. I don't understand why they
made an exception here.



Even C and
C++ have non-short circuit versions of And ( & ) and Or ( | ) - they're
simply not used much.
Click to expand...



The non short circuit feature should not have been removed, the
operators should simply have been renamed. The article said the
names BitAnd and BitOr were considered. Those seem fine to me.




Changing the behavior of And and Or would have caused
nearly 100% of all VB 6 programs to break upon porting to VB.Net (any
version).
Click to expand...



Most programs broke on importing anyway, until they were
extensively modified (at least mine did). But, I don't see that
this is a case that would cause programs to break. The upgrade
wizard would simply have changed all Ands and Ors to BitAnds and
BitOrs. But, even if it didn't do that, I doubt very many
programs would have broken. Like you said WRT C and C++, the non
short circuited versions of the commands are not used much. I
doubt there were very many VB6 programs that relied on that
behaviour. Instead, I suspect that most programs tried to work
around it.




Greg








 
Herfried,
"Logical" doesn't mean "short circuiting". 'Or' and 'And' are logical and
bitwise, depending on the situation.
Click to expand...
Who did write that it was not like that?

Cor
 
Michael,

Why in probably 99% of the situations the OR and AND in VB6 were used as
logical operators. Just setting an warning at the others as so much is done
would have cleared the future for VB, now we are sticked forever with that
crazy ORELSE andalso ANDALSO.

Just my opinion, but it does not help anything anymore.

Cor

Michael D. Ober said:
In the cases of AndAlso vs. And and OrElse vs. Or, the issue MS had to
struggle with was that VB 6 and earlier didn't short circuit the
conditional evaluation and a lot of existing code depended on this
behavior. Even C and C++ have non-short circuit versions of And ( & ) and
Or ( | ) - they're simply not used much. Changing the behavior of And and
Or would have caused nearly 100% of all VB 6 programs to break upon
porting to VB.Net (any version).

Mike Ober
Click to expand...
 
Michael D. Ober said:
In the cases of AndAlso vs. And and OrElse vs. Or,
snip

Changing the behavior of And and Or would have caused nearly 100% of all
VB 6 programs to break upon porting to VB.Net (any version).
Click to expand...

Is this true? I assume you mean bitwise use of "and".

I haven't been able to find a single example of code that would require
"and" as opposed to andalso.

To put it another way:
Are there any circumstances where I would want to use the old
"and"?

Al G
 
Is this true? I assume you mean bitwise use of "and".

I haven't been able to find a single example of code that would require
"and" as opposed to andalso.

To put it another way:
Are there any circumstances where I would want to use the old
"and"?

Al G
Click to expand...

Very rarely would I ever use the "old and". Very few of my projects
don't make use of the short-circuit evaluation of the AndAlso
statement. But consider the following:

////////////////////
Public Sub placeOrder_Click(ByVal sender As Object, ByVal e As
EventArgs) Handles placeOrder.Click
If IsItemOnHand() And ItemCanBeShipped() Then

End If
End Sub

Public Function IsItemOnHand() As Boolean
'// Check a database in a real world application
'// Here I'm simulating a failure
Dim onHand As Boolean = False

'// In a real world app, you could log an event if
'// the item wasn't on hand when the order was placed
If Not onHand Then LogEvent("Order Attempted on Unavailable
Item")

Return onHand
End Function

Public Function ItemCanBeShipped() As Boolean
'// Check a database in a real world application
'// Here I'm simulating a failure
Dim canBeShipped As Boolean = False

'// In a real world app, you could log an event if
'// the item wasn't on hand when the order was placed
If Not canBeShipped Then LogEvent("Order Attempted on
Unshippable Item")

Return canBeShipped
End Function

Public Sub PlaceOrder()
'// Save the order to a database in a real world app
End Sub

Public Sub LogEvent(ByVal eventDescription As String)
'// Log the event here
End Sub
/////////////////////

As you'll see the code simulates an order placement class. Two checks
are made when the user clicks the button to place an order, first it
checks to see if the item is available, and second it checks to see it
the item can be shipped. In each function, an event is logged if the
item doesn't meet the necessary requirements. In a real world
application these events would be monitored and used to prevent
unavailable and unshippable items from being ordered.

Using the "And" statement forces both functions to fire - which in
this case is good as it forces a check to make sure the item is also
shippable, even if the item wasn't on hand. If we switch to "AndAlso"
only the the unavailable item event would be logged, thus hiding an
important message (unshippable item) from the monitoring - which could
cause more problems when the unshippable item becomes available.

I realize that might be a confusing example - so please ask if you
need me to clarify any points.

Thanks,

Seth Rowe
 
Public Sub placeOrder_Click(ByVal sender As Object, ByVal e As
EventArgs) Handles placeOrder.Click
If IsItemOnHand() And ItemCanBeShipped() Then

End If
End Sub
Click to expand...

Should be:

Public Sub placeOrder_Click(ByVal sender As Object, ByVal e As
EventArgs) Handles placeOrder.Click
If IsItemOnHand() And ItemCanBeShipped() Then
PlaceOrder()
End If
End Sub

Thanks,

Seth Rowe
 
rowe_newsgroups said:
Very rarely would I ever use the "old and". Very few of my projects
don't make use of the short-circuit evaluation of the AndAlso
statement. But consider the following:

////////////////////
Public Sub placeOrder_Click(ByVal sender As Object, ByVal e As
EventArgs) Handles placeOrder.Click
If IsItemOnHand() And ItemCanBeShipped() Then

End If
End Sub

Public Function IsItemOnHand() As Boolean
'// Check a database in a real world application
'// Here I'm simulating a failure
Dim onHand As Boolean = False

'// In a real world app, you could log an event if
'// the item wasn't on hand when the order was placed
If Not onHand Then LogEvent("Order Attempted on Unavailable
Item")

Return onHand
End Function

Public Function ItemCanBeShipped() As Boolean
'// Check a database in a real world application
'// Here I'm simulating a failure
Dim canBeShipped As Boolean = False

'// In a real world app, you could log an event if
'// the item wasn't on hand when the order was placed
If Not canBeShipped Then LogEvent("Order Attempted on
Unshippable Item")

Return canBeShipped
End Function

Public Sub PlaceOrder()
'// Save the order to a database in a real world app
End Sub

Public Sub LogEvent(ByVal eventDescription As String)
'// Log the event here
End Sub
/////////////////////

As you'll see the code simulates an order placement class. Two checks
are made when the user clicks the button to place an order, first it
checks to see if the item is available, and second it checks to see it
the item can be shipped. In each function, an event is logged if the
item doesn't meet the necessary requirements. In a real world
application these events would be monitored and used to prevent
unavailable and unshippable items from being ordered.

Using the "And" statement forces both functions to fire - which in
this case is good as it forces a check to make sure the item is also
shippable, even if the item wasn't on hand. If we switch to "AndAlso"
only the the unavailable item event would be logged, thus hiding an
important message (unshippable item) from the monitoring - which could
cause more problems when the unshippable item becomes available.

I realize that might be a confusing example - so please ask if you
need me to clarify any points.

Thanks,

Seth Rowe
Click to expand...

Thank you, that is a very good example.

Al G
 
Back
Top