Jeder - na ja, fast jeder ... - kennt die logischen Vergleichsoperatoren "and" und "or". Die sind quasi Basic-Urgestein und auch in VB.Net zu finden. In VB.Net gibt's allerdings auch noch "andalso" und "orelse", was sich etwa nach "und auch" bzw "oder sonst" übersetzen läßt. Die machen grundsätzlich das Gleiche, warum also zwei neue Vokabeln?
Historisch (VB6 und Vorgänger) ist es immer so gewesen, dass bei Verwendung von "and" und "or" immer ALLE Teile des Ausdrucks "berechnet" (evaluiert) wurden:
If a > 1 And a < 10 Then
Jetzt wird erst geprüft, ob a größer als 1 ist und dann noch, ob a kleiner als 10 ist. Wie man sieht ist das "eigentlich" Unsinn, denn wenn a zB Null ist, kann man ja eigentlich aufhören mit prüfen, denn der GESAMTE Ausdruck kann ja nie mehr "true" (wahr) sein.
Umgekehrtes gilt natürlich für "or". Wenn der erste Ausdruck schon "true" ist, ist alles was danach kommt ziemlich egal, denn "or" liefert ja schon "true" wenn einer der Ausdrücke "true" ist.
Für genau diese "Abkürzung" gibt es in VB.Net jetzt "AndAlso" und "OrElse". Hierbei wird dann nur solange geprüft, wie es - rein menschlich gesehen - "Sinn" macht. D.h. wenn bei AndAlso der erste Ausdruck schon "false" ist, wird die weitere Überprüfung abgebrochen, da es ja eh nie mehr "true" werden kann. Analog bei "OrElse" wird solange geprüft, bis ein Ausdruck "true" ist, da ja dann der Gesamtausdruck "true" ist.
Warum hat man nicht einfach das Verhalten von "or" und "and" angepasst? Zum einen aus Kompatibilitätsgründen und weil es manchmal Situationen gibt, in denen auf jeden alle Teile geprüft werden sollen. Das könnte zb sein, wenn man eine Function aufruft (die true oder false zurückliefert) und die bei jeden Durchlauf der Prüfung aufgerufen werden soll - warum auch immer, aber es gibt solche Fälle, wenn auch ggfs selten.
Was heißt das?
1. Im Zweifel (!) sollte man statt "and" und "or" immer "andalso" und "orelse" verwenden!
2. Man sollte seine Ausdrücke so sortieren, dass die wahrscheinlichste Abbruchbedingung (bei andalso -> false und bei orelse -> true) ZUERST geprüft wird.
Die Verwendung gerade von "AndAlso" hat noch einen weiteren Vorteil, der dann zum Tragen kommt, wenn man mit Objekten arbeitet, die ja ggfs "Nothing" sind.
Anhang:
MSIL Listing mit den 4 verschiedenen Varianten.
Nachtrag/Edit:
Ich hab mal ein paar kleine Benchalgos geschrieben, die das ganze verdeutlichen.
Die entscheidenden Zeilen (die jeweils 10 Mio. Mal aufgerufen werden):
Die Zeiten:
1: 0,670839276
2: 0,375900016
3: 0,366639636
4: 1,664589456
5: 1,367523228
6: 0,380902164
Man sieht dass bei den ersten drei (wobei beide Prüfungen verhältnissmäßig "billig" sind) das Konstrukt mit "And" deutlich langsamer ist, bei "AndAlso" aber kein SO großer Unterschied besteht.
Bei den anderen drei ist "And" immer noch deutlich langsamer, aber der Hauptunterschied besteht zwischen den letzten beiden. Da hier die "teure" Bedingung (Berechnung der wurzel ist deutlich langsamer als ne Ganzahldivision mit Rest!), wenn sie als zweites geprüft wird, nicht mehr so oft berechnet werden muss, sind die Zeiten extrem unterschiedlich.
Wie man sieht, kann man also durch die Verwendung von "AndAlso" und der richtigen Reihenfolge in Einzelfällen bis zu 3/4 Rechenzeit einsparen. Wenn das ganze nur einmal benötigt wird, ist das natürlich irrelevant, aber wenn das ganze in einer Schleife passiert, sollte man sich das mal überlegen!
Historisch (VB6 und Vorgänger) ist es immer so gewesen, dass bei Verwendung von "and" und "or" immer ALLE Teile des Ausdrucks "berechnet" (evaluiert) wurden:
If a > 1 And a < 10 Then
Jetzt wird erst geprüft, ob a größer als 1 ist und dann noch, ob a kleiner als 10 ist. Wie man sieht ist das "eigentlich" Unsinn, denn wenn a zB Null ist, kann man ja eigentlich aufhören mit prüfen, denn der GESAMTE Ausdruck kann ja nie mehr "true" (wahr) sein.
Umgekehrtes gilt natürlich für "or". Wenn der erste Ausdruck schon "true" ist, ist alles was danach kommt ziemlich egal, denn "or" liefert ja schon "true" wenn einer der Ausdrücke "true" ist.
Für genau diese "Abkürzung" gibt es in VB.Net jetzt "AndAlso" und "OrElse". Hierbei wird dann nur solange geprüft, wie es - rein menschlich gesehen - "Sinn" macht. D.h. wenn bei AndAlso der erste Ausdruck schon "false" ist, wird die weitere Überprüfung abgebrochen, da es ja eh nie mehr "true" werden kann. Analog bei "OrElse" wird solange geprüft, bis ein Ausdruck "true" ist, da ja dann der Gesamtausdruck "true" ist.
Warum hat man nicht einfach das Verhalten von "or" und "and" angepasst? Zum einen aus Kompatibilitätsgründen und weil es manchmal Situationen gibt, in denen auf jeden alle Teile geprüft werden sollen. Das könnte zb sein, wenn man eine Function aufruft (die true oder false zurückliefert) und die bei jeden Durchlauf der Prüfung aufgerufen werden soll - warum auch immer, aber es gibt solche Fälle, wenn auch ggfs selten.
Was heißt das?
1. Im Zweifel (!) sollte man statt "and" und "or" immer "andalso" und "orelse" verwenden!
2. Man sollte seine Ausdrücke so sortieren, dass die wahrscheinlichste Abbruchbedingung (bei andalso -> false und bei orelse -> true) ZUERST geprüft wird.
Die Verwendung gerade von "AndAlso" hat noch einen weiteren Vorteil, der dann zum Tragen kommt, wenn man mit Objekten arbeitet, die ja ggfs "Nothing" sind.
VB.NET-Quellcode
- dim s as System.IO.Stream
- If s IsNot Nothing and s.seek(...) Then
- -> Fehler! Denn s ist zwar Nothing, aber dennoch wird der zweite Teil ausgeführt und da gibt's dann den Fehler WEIL s ja nothing ist!
- If s IsNot Nothing AndAlso s.Seek() Then
- -> Kein Problem! s ist nothing, deswegen wird der zweite Teil gar nicht angefasst!
Anhang:
MSIL Listing mit den 4 verschiedenen Varianten.
Nachtrag/Edit:
Ich hab mal ein paar kleine Benchalgos geschrieben, die das ganze verdeutlichen.
Die entscheidenden Zeilen (die jeweils 10 Mio. Mal aufgerufen werden):
VB.NET-Quellcode
- 1 If (j Mod 100) = 0 And (j Mod 10000) = 0 Then
- 2 If (j Mod 100) = 0 AndAlso (j Mod 10000) = 0 Then
- 3 If (j Mod 10000) = 0 AndAlso (j Mod 100) = 0 Then
- 4 If CInt(Math.Sqrt(j)) Mod 10 = 0 And (j Mod 100) = 0 Then
- 5 If CInt(Math.Sqrt(j)) Mod 10 = 0 AndAlso (j Mod 100) = 0 Then
- 6 If (j Mod 100) = 0 AndAlso CInt(Math.Sqrt(j)) Mod 10 = 0 Then
Die Zeiten:
1: 0,670839276
2: 0,375900016
3: 0,366639636
4: 1,664589456
5: 1,367523228
6: 0,380902164
Man sieht dass bei den ersten drei (wobei beide Prüfungen verhältnissmäßig "billig" sind) das Konstrukt mit "And" deutlich langsamer ist, bei "AndAlso" aber kein SO großer Unterschied besteht.
Bei den anderen drei ist "And" immer noch deutlich langsamer, aber der Hauptunterschied besteht zwischen den letzten beiden. Da hier die "teure" Bedingung (Berechnung der wurzel ist deutlich langsamer als ne Ganzahldivision mit Rest!), wenn sie als zweites geprüft wird, nicht mehr so oft berechnet werden muss, sind die Zeiten extrem unterschiedlich.
Wie man sieht, kann man also durch die Verwendung von "AndAlso" und der richtigen Reihenfolge in Einzelfällen bis zu 3/4 Rechenzeit einsparen. Wenn das ganze nur einmal benötigt wird, ist das natürlich irrelevant, aber wenn das ganze in einer Schleife passiert, sollte man sich das mal überlegen!
