Dans VB.NET, quelle est la différence entre And
et AndAlso
? Que dois-je utiliser?
Dans VB.NET, quelle est la différence entre And
et AndAlso
? Que dois-je utiliser?
Réponses:
L' And
opérateur évalue les deux côtés, où AndAlso
évalue le côté droit si et seulement si le côté gauche est vrai.
Un exemple:
If mystring IsNot Nothing And mystring.Contains("Foo") Then
' bla bla
End If
Ce qui précède lève une exception si mystring = Nothing
If mystring IsNot Nothing AndAlso mystring.Contains("Foo") Then
' bla bla
End If
Celui-ci ne lève pas d'exception.
Donc, si vous venez du monde C #, vous devez utiliser AndAlso
comme vous le feriez &&
.
Plus d'informations ici: http://www.panopticoncentral.net/2003/08/18/the-ballad-of-andalso-and-orelse/
Then
c'est son propre mot-clé.
L' And
opérateur vérifiera toutes les conditions dans la déclaration avant de continuer, tandis que l'opérateur Andalso s'arrêtera s'il sait que la condition est fausse. Par exemple:
if x = 5 And y = 7
Vérifie si x est égal à 5 et si y est égal à 7, puis continue si les deux sont vrais.
if x = 5 AndAlso y = 7
Vérifie si x est égal à 5. Sinon, il ne vérifie pas si y est 7, car il sait que la condition est déjà fausse. (C'est ce qu'on appelle un court-circuit.)
Généralement, les gens utilisent la méthode de court-circuit s'il y a une raison de ne pas vérifier explicitement la deuxième partie si la première partie n'est pas vraie, comme si elle lèverait une exception si elle était cochée. Par exemple:
If Not Object Is Nothing AndAlso Object.Load()
Si cela était utilisé à la And
place de AndAlso
, il essaierait Object.Load()
quand même de le faire nothing
, ce qui lèverait une exception.
and
/ à or
moins d'avoir une raison - dont je pense que les légitimes sont rares. Il y a sûrement une raison pour laquelle la plupart des autres langues court-circuitent par défaut: elles conservent le sens du résultat tout en n'évaluant pas les expressions potentiellement coûteuses lorsqu'elles ne contribuent en rien. Les effets secondaires cachés dans des conditions devraient être, bien, aux yeux latéraux. Mais c'est juste mon opinion ...
Fait intéressant, aucune des réponses n'a mentionné que And
et Or
dans VB.NET sont des opérateurs de bits alors que OrElse
et AndAlso
sont strictement des opérateurs booléens.
Dim a = 3 OR 5 ' Will set a to the value 7, 011 or 101 = 111
Dim a = 3 And 5 ' Will set a to the value 1, 011 and 101 = 001
Dim b = 3 OrElse 5 ' Will set b to the value true and not evaluate the 5
Dim b = 3 AndAlso 5 ' Will set b to the value true after evaluating the 5
Dim c = 0 AndAlso 5 ' Will set c to the value false and not evaluate the 5
Remarque : un entier non nul est considéré true
; Dim e = not 0
sera mis e
à -1
démontrer Not
est également un opérateur peu.
||
et &&
(les versions C # de OrElse
et AndAlso
) renvoient la dernière expression évaluée qui serait 3
et 5
respectivement. Cela vous permet d'utiliser l'idiome v || 5
en C # pour donner 5
comme valeur de l'expression quand v
est null
ou ( 0
et un entier) et la valeur de v
sinon. La différence de sémantique peut surprendre un programmeur C # qui barboterait dans VB.NET car cet "idiome de valeur par défaut" ne fonctionne pas dans VB.NET.
Donc, pour répondre à la question : Utilisez Or
et And
pour les opérations sur les bits (entier ou booléen). Utilisez OrElse
et AndAlso
pour "court-circuiter" une opération pour gagner du temps, ou testez la validité d'une évaluation avant de l'évaluer. If valid(evaluation) andalso evaluation then
ouif not (unsafe(evaluation) orelse (not evaluation)) then
Bonus: Quelle est la valeur des éléments suivants?
Dim e = Not 0 And 3
||
et &&
avec ??
. Bien qu'il existe des langages où ||
retournera la valeur non-falsey, C # n'en fait pas partie et retourne un bool
(sauf pour les opérateurs annulés levés, où vous obtenez un Nullable<bool>
résultat)
If Bool1 And Bool2 Then
Évalue à la fois Bool1 et Bool2
If Bool1 AndAlso Bool2 Then
Évalue Bool2 si et seulement si Bool1 est vrai.
Juste pour tous ceux qui disent que les effets secondaires sont mauvais: un endroit où avoir deux effets secondaires dans une condition est bon serait de lire deux objets fichier en tandem.
While File1.Seek_Next_Row() And File2.Seek_Next_Row()
Str1 = File1.GetRow()
Str2 = File2.GetRow()
End While
L'utilisation de la And
garantit qu'une ligne est consommée chaque fois que la condition est vérifiée. Alors que AndAlso
pourrait lire la dernière ligne de File1
et laisser File2
sans ligne consommée.
Bien sûr, le code ci-dessus ne fonctionnerait pas, mais j'utilise tout le temps des effets secondaires comme celui-ci et je ne le considérerais pas comme un code " mauvais " ou " diabolique " comme certains pourraient vous le faire croire. C'est facile à lire et efficace.
AndAlso ressemble beaucoup à And, sauf qu'il fonctionne comme && en C #, C ++, etc.
La différence est que si la première clause (celle qui précède AndAlso) est vraie, la deuxième clause n'est jamais évaluée - l'expression logique composée est "court-circuitée".
Ceci est parfois très utile, par exemple dans une expression telle que:
If Not IsNull(myObj) AndAlso myObj.SomeProperty = 3 Then
...
End If
L'utilisation de l'ancien Et dans l'expression ci-dessus lèverait une NullReferenceException si myObj était null.
Voir également la question Stack Overflow: Dois-je toujours utiliser les opérateurs AndAlso et OrElse? .
Aussi: Un commentaire pour ceux qui ont mentionné l'utilisation And
si le côté droit de l'expression a un effet secondaire dont vous avez besoin:
Si le côté droit a un effet secondaire dont vous avez besoin, déplacez-le simplement vers le côté gauche plutôt que d'utiliser "Et". Vous n'avez vraiment besoin de "Et" que si les deux côtés ont des effets secondaires. Et si vous avez autant d'effets secondaires, vous faites probablement autre chose de mal. En général, vous devriez vraiment préférer AndAlso.
En plus des réponses ci-dessus, AndAlso propose également un processus de conditionnement connu sous le nom de court-circuit. De nombreux langages de programmation intègrent cette fonctionnalité comme vb.net et peuvent fournir des augmentations de performances substantielles dans les déclarations de condition longue en supprimant les évaluations inutiles.
Une autre condition similaire est la condition OrElse qui ne vérifierait la bonne condition que si la condition de gauche est fausse, supprimant ainsi les vérifications de condition inutiles après qu'une vraie condition a été trouvée.
Je vous conseille de toujours utiliser des processus de court-circuitage et de structurer vos instructions conditionnelles de la manière la plus avantageuse. Par exemple, testez d'abord vos conditions les plus efficaces et les plus rapides afin de ne courir vos longues conditions que lorsque vous en avez absolument besoin et de court-circuiter les autres fois.
Pour la majorité d'entre nous, OrElse et AndAlso feront l'affaire à l'exception de quelques exceptions déroutantes (moins de 1% où nous devrons peut-être utiliser Or et And).
Essayez de ne pas vous laisser emporter par les gens montrant leurs logiques booléennes et les faisant ressembler à une science de fusée.
C'est assez simple et direct et parfois votre système peut ne pas fonctionner comme prévu car il n'aime pas votre logique en premier lieu. Et pourtant, votre cerveau ne cesse de vous dire que sa logique est testée et éprouvée à 100% et qu'elle devrait fonctionner. À ce moment précis, arrêtez de faire confiance à votre cerveau et demandez-lui de réfléchir à nouveau ou (pas OrElse ou peut-être OrElse) de vous forcer à chercher un autre travail qui ne nécessite pas beaucoup de logique.
Cas d'utilisation:
Avec «Et», le compilateur vérifiera toutes les conditions, donc si vous vérifiez qu'un objet pourrait être «Rien» et que vous vérifiez l'une de ses propriétés, vous aurez une erreur d'exécution.
Mais avec AndAlso avec le premier "faux" dans les conditions il vérifiera le suivant donc vous n'aurez pas d'erreur.