que - sentencia switch java
&&(AND) y ||(O) en declaraciones IF (9)
El cortocircuito aquí significa que la segunda condición no será evaluada.
Si (A && B) se producirá un cortocircuito si A es falso.
Si (A && B) no dará lugar a cortocircuito si A es verdadero.
Si (A || B) se producirá un cortocircuito si A es verdadero.
Si (A || B) no dará lugar a un cortocircuito si A es falso.
Tengo el siguiente código:
if(!partialHits.get(req_nr).containsKey(z) || partialHits.get(req_nr).get(z) < tmpmap.get(z)){
partialHits.get(z).put(z, tmpmap.get(z));
}
donde partialHits es un HashMap.
¿Qué pasará si la primera afirmación es verdadera? ¿Seguirá Java controlando la segunda declaración? Porque para que la primera declaración sea verdadera, HashMap no debe contener la clave dada, por lo que si la segunda declaración está marcada, obtendré NullPointerException .
Entonces en palabras simples, si tenemos el siguiente código
if(a && b)
if(a || b)
¿verifica Java b si a es falso en el primer caso y si a es verdadero en el segundo caso?
Esto se remonta a la diferencia básica entre & y &&, | y ||
Por cierto, realiza las mismas tareas muchas veces. No estoy seguro si la eficiencia es un problema. Puede eliminar parte de la duplicación.
Z z2 = partialHits.get(req_nr).get(z); // assuming a value cannout be null.
Z z3 = tmpmap.get(z); // assuming z3 cannot be null.
if(z2 == null || z2 < z3){
partialHits.get(z).put(z, z3);
}
Java tiene 5 operadores diferentes de comparación booleana: &, &&, |, ||, ^
& y && son operadores "y", | y || "o" operadores, ^ es "xor"
Los únicos verificarán cada parámetro, independientemente de los valores, antes de verificar los valores de los parámetros. Los dobles primero verifican el parámetro izquierdo y su valor y si es true ( || ) o false ( && ) dejan intacto el segundo. Sonido compilado? Un ejemplo fácil debería dejarlo claro:
Dado para todos los ejemplos:
String aString = null;
Y:
if (aString != null & aString.equals("lala"))
Ambos parámetros se verifican antes de realizar la evaluación y se lanza una NullPointerException para el segundo parámetro.
if (aString != null && aString.equals("lala"))
El primer parámetro se verifica y devuelve false , por lo que no se comprobará el segundo parámetro, porque el resultado es false todos modos.
Lo mismo para O:
if (aString == null | !aString.equals("lala"))
Levantará NullPointerException, también.
if (aString == null || !aString.equals("lala"))
El primer parámetro se verifica y devuelve true , por lo que el segundo parámetro no se comprobará, porque el resultado es true todos modos.
XOR no se puede optimizar, ya que depende de ambos parámetros.
No, no lo hará, Java se cortocircuitará y dejará de evaluar una vez que conozca el resultado.
No, no será evaluado. Y esto es muy útil. Por ejemplo, si necesita probar si una Cadena no es nula o está vacía, puede escribir:
if (str != null && !str.isEmpty()) {
doSomethingWith(str.charAt(0));
}
O al revés
if (str == null || str.isEmpty()) {
complainAboutUnusableString();
} else {
doSomethingWith(str.charAt(0));
}
Si no tuviéramos ''cortocircuitos'' en Java, recibiríamos muchas NullPointerExceptions en las líneas de código anteriores.
No, no será verificado. Este comportamiento se denomina evaluación de cortocircuito y es una característica en muchos idiomas, incluido Java.
No, si a es verdadero (en a or prueba), b no se probará, ya que el resultado de la prueba siempre será verdadero, cualquiera que sea el valor de la expresión b.
Haz una prueba simple:
if (true || ((String) null).equals("foobar")) {
...
}
no lanzará una NullPointerException !
Sí, la evaluación de cortocircuito para expresiones booleanas es el comportamiento predeterminado en toda la familia tipo C.
Un hecho interesante es que Java también usa el & y | como operandos lógicos (están sobrecargados, con tipos int son las operaciones bit a bit esperadas) para evaluar todos los términos en la expresión, lo que también es útil cuando se necesitan los efectos colaterales.
Todas las respuestas aquí son geniales, pero, para ilustrar de dónde viene esto, para preguntas como esta, es bueno ir a la fuente: la Especificación del lenguaje Java.
Sección 15:23, Condicional-Y operador (&&) , dice:
El operador && es como & (§15.22.2), pero evalúa su operando de la mano derecha solo si el valor de su operando de la izquierda es verdadero. [...] En tiempo de ejecución, la expresión del operando de la izquierda se evalúa primero [...] si el valor resultante es falso, el valor de la expresión condicional y es falsa y la expresión del operando de la derecha no se evalúa . Si el valor del operando de la izquierda es verdadero, entonces la expresión de la mano derecha se evalúa [...] el valor resultante se convierte en el valor de la expresión condicional. Por lo tanto, && calcula el mismo resultado que & en operandos booleanos. Solo difiere en que la expresión del operando de la derecha se evalúa condicionalmente en lugar de siempre.
Y de manera similar, la Sección 15:24, Operador Condicional O (||) , dice:
El || el operador es como | (§15.22.2), pero evalúa su operando de la mano derecha solo si el valor de su operando de la mano izquierda es falso. [...] En tiempo de ejecución, la expresión del operando de la izquierda se evalúa primero; [...] si el valor resultante es verdadero, el valor de la expresión condicional es verdadero y la expresión del operando de la derecha no se evalúa. Si el valor del operando de la izquierda es falso, entonces se evalúa la expresión de la mano derecha; [...] el valor resultante se convierte en el valor de la expresión condicional. Por lo tanto, || calcula el mismo resultado que | en operandos booleanos o booleanos. Solo difiere en que la expresión del operando de la derecha se evalúa condicionalmente en lugar de siempre.
Un poco repetitivo, tal vez, pero la mejor confirmación de cómo funcionan exactamente. De forma similar, el operador condicional (? :) solo evalúa la "mitad" apropiada (la mitad izquierda si el valor es verdadero, la mitad derecha si es falsa), lo que permite el uso de expresiones como:
int x = (y == null) ? 0 : y.getFoo();
sin una NullPointerException.