vb.net - operador - (OrElse and Or) y(AndAlso and And)-¿Cuándo usar?

operador andalso

Question

¿Cuál es la diferencia entre (OrElse y Or) y (AndAlso and And)? ¿Hay alguna diferencia en sus actuaciones, digamos que el beneficio de la corrección? ¿Hay alguna situación en la que no use OrElse y AndAlso?

Answer 1

@Gideon - me alegro de que alguien lo haya señalado. Aquí hay una prueba simple que muestra el impacto dramático de AndAlso:

    Dim tm As New Stopwatch
    Const tries As Integer = 123456
    Dim z As Integer = 0
    Dim s() As String = New String() {"0", "one"}

    Debug.WriteLine("AndAlso")
    For x As Integer = 0 To s.Length - 1
        z = 0
        tm.Restart() ''restart the stopwatch
        For y As Integer = 0 To tries
            If s(x) = x.ToString AndAlso s(x) = y.ToString Then ''<<<<<<<<<<
                z += 1
            End If
        Next
        tm.Stop()
        Debug.WriteLine(x.ToString.PadRight(3, " "c) & z.ToString.PadRight(10, " "c) & tm.Elapsed.ToString)
    Next

    Debug.WriteLine("And")
    For x As Integer = 0 To s.Length - 1
        z = 0
        tm.Restart() ''restart the stopwatch
        For y As Integer = 0 To tries
            If s(x) = x.ToString And s(x) = y.ToString Then ''<<<<<<<<<<
                z += 1
            End If
        Next
        tm.Stop()
        Debug.WriteLine(x.ToString.PadRight(3, " "c) & z.ToString.PadRight(10, " "c) & tm.Elapsed.ToString)
    Next

Answer 2

Además del cortocircuito mencionado en las otras respuestas, Or / And son utilizables como operadores bit a bit donde OrElse / AndAlso no lo son. Las operaciones de bit a bit incluyen la combinación de valores de enumeraciones de Flags, como la enumeración de FileAttributes donde se puede indicar que un archivo es de solo lectura y está oculto por FileAttributes.ReadOnly Or FileAttributes.Hidden

Answer 3

La diferencia es que OrElse y And también se cortocircuitarán en función de la primera condición, lo que significa que si la primera condición no pasa, la segunda (o más) condiciones no se evaluarán. Esto es particularmente útil cuando una de las condiciones puede ser más intensa que la otra.

Ejemplo donde Or está bien (ambas condiciones evaluadas):

If Name = "Fred" Or Name = "Sam" Then

Realmente no importa en qué dirección se evalúan

El siguiente AndAlso es útil porque la segunda condición podría fallar

If Not SomeObject Is Nothing AndAlso CheckObjectExistsInDatabase(SomeObject) Then

Esto permite que la primera condición compruebe si el objeto se ha configurado y solo si se ha configurado irá y comprobará la base de datos (o alguna otra tarea). Si esto hubiera sido una palabra clave simple, ambos serían evaluados.

Answer 4

Or/And siempre evaluará ambas expresiones y luego devolverá un resultado. No están en cortocircuito.

OrElse/AndAlso están short-circuiting . La expresión correcta solo se evalúa si el resultado no puede determinarse a partir de la evaluación de la expresión izquierda sola. (Eso significa que: OrElse solo evaluará la expresión correcta si la expresión de la izquierda es falsa, y AndAlso solo evaluará la expresión correcta si la expresión de la izquierda es verdadera).

Suponiendo que no se producen efectos secundarios en las expresiones y las expresiones no son dependientes (y se ignora cualquier sobrecarga de ejecución), entonces son las mismas.

Sin embargo, en muchos casos es que las expresiones son dependientes. Por ejemplo, queremos hacer algo cuando una Lista no es-Nada y tiene más de un elemento:

If list IsNot Nothing AndAlso list.Length > 0 Then .. ''list has stuff

Esto también se puede usar para evitar un cálculo "caro" (o efectos secundarios, ick!):

If Not Validate(x) OrElse Not ExpensiveValidate(x) Then .. ''not valid

Personalmente, considero que AndAlso y OrElse son los operadores correctos para usar en todos menos en el 1% o menos, con suerte. - de los casos donde se desea un efecto secundario.

Feliz codificación.

¹ Una excepción lanzada en la primera expresión evitará que se evalúe la segunda expresión, pero esto no debería sorprender.