0

What is an instance where And would be favored over AndAlso when evaluating expressions? I have assumed the earlier keyword only existed for backwards compatibility but still come across examples using And.

Thanks!

-- Question has been edited as requested to make it (more?) unique.

I read this question What is the difference between And and AndAlso in VB.NET?

I understand the conceptual differences of And and AndAlso which is not what I've asked as can be discerned by reading. With that, I fail to see how this is a duplicate question which already has a stellar answer by Jon Hanna.

Again, thanks.

Community
  • 1
  • 1
Steven Kirkland
  • 25
  • 8
  • 2
    possible duplicate of [What is the difference between And and AndAlso in VB.net?](http://stackoverflow.com/questions/302047/what-is-the-difference-between-and-and-andalso-in-vb-net) – David Aug 10 '15 at 14:06
  • How about if you're testing for the Boolean result of multiple functions? If PostToAccounts() And RollOverTax() And PayEmployee() ? – Andrew Mortimer Aug 10 '15 at 14:07
  • 1
    In the linked question, [this is the first answer](http://stackoverflow.com/a/4811404/791010) that addresses your question as to why you _might_ want to use `And` instead of `AndAlso`. – James Thorpe Aug 10 '15 at 14:09
  • 1
    `And` is the only way to perform bitwise operations in VB (as mentioned in the duplicate) – Matt Wilko Aug 10 '15 at 14:14

1 Answers1

4

There are three reasons you might use And rather than AndAlso (and while VB.Net operators are not always directly comparable with C# operators, this does apply to & vs && in C# too).

The first is when you are not comparing boolean values, but doing a bit-wise comparison. 

13 And 92     ' 12
13 AndAlso 92 ' True

The second is when you want to ensure that both expressions are calculated because of a side effect. However, in such a case I'd recommend you calculate them first and then do the And or AndAlso after, to make for clearer code.

The third is to avoid branching. Consider that:

If x AndAlso y Then
' Do something
End If

Works much the same as:

If x Then
  If y Then
  ' Do Something
  End If
End If

Now, with the way that modern computers work, processors will have read some of the next instructions before knowing whether those are really the next instructions or not, because it has yet to work out whether it will follow an If branch or not. There's some clever stuff guessing about whether a branch will be taken or not, but that clever stuff is still just guessing. If it guesses wrong then it has to back up and this slows things down.

Therefore if calculating the second argument to an AndAlso takes less than a certain threshold, a And could in fact be faster, because while there is conceptually more work done in with an And than an AndAlso in the case where the first argument was False (allowing the AndAlso to short-circuit) there's only one branch to predict rather than two, and the odds of correctly guessing which the branching is greater. (Search for "branch prediction" and "branch misprediction" here for more on that general issue).

Jon Hanna
  • 102,999
  • 9
  • 134
  • 232
  • Your comments about processor speculative execution make me wonder how smart the vb/c# compilers and .NET jitter are in this area - ie whether it can tell if there are side affects when using `AndAlso` and convert them to speculative-execution-friendly code if not... Another topic to add to a growing list of things to investigate... – James Thorpe Aug 10 '15 at 14:31
  • @JamesThorpe for the most part no, though there may be exceptions. One issue would be that generally its very hard to predict from just the code alone which branch would be more common; and to the extent that it is, then the branch predictor is already doing such work anyway. The odds depend on the actual data processed as well as the relative costs of the expressions in themselves, so it takes a bigger-picture view to make a reasonable guess to when `And` will be faster than `AndAlso`.You could though note how the lifting of nullable values tends to use `And/&` rather than `AndAlso/&&` in how – Jon Hanna Aug 10 '15 at 14:44
  • @JamesThorpe ... it combines the check on `HasValue` with getting the result from `GetValueOrDefault` to produce the lifted operator result. – Jon Hanna Aug 10 '15 at 14:46
  • @JamesThorpe if nothing else, it would be really annoying if you attempted to apply such higher level knowledge (or just profiled both to see which did better), and the compiler decided it knew better than you and turned the different approaches into the same code either way. – Jon Hanna Aug 10 '15 at 14:49
  • Even more annoying if the compiler turned out to be right :) – James Thorpe Aug 10 '15 at 14:50
  • @JamesThorpe I'd be happy if the compiler picked well with most of my code, since with most of my code I generally use `&&` unless I've a good reason to suspect `&` would be better, which is rarely. I'd be much less happy in those cases where I try both and profile it with sample data so as to actually *know* which was faster. – Jon Hanna Aug 10 '15 at 15:09
  • @JonHanna I found myself looking up my own questions again and, again, checking the marked duplicate answer. After re-reading the _marked as duplicate_ question answers half-dozen time, I finally see the connection that it was a quasi-duplicate. But I don't think that, without the input you'd provided, my laymen person brain would have finally understood. So now, this comment also becomes that which StackOverflow doesn't like for comments; I appreciate the time you took to answer this _duplicate_ and my apologies being not smart as StackOverflow's preferred target audience. – Steven Kirkland Jan 04 '18 at 15:12
  • 1
    @StevenKirkland I agree it's a close but not exact duplicate. One could very well read much of that question and not have a good answer to "well, why not use `AndAlso` all the time?". There is an answer there about wanting to have both side-effects, but personally I think if you need both side effects it's better to have them as separate statements to be clearer as I said. Nobody raised the issue of branching there. – Jon Hanna Jan 04 '18 at 15:31