optimization - steps - ¿"If([bool]== true)" requiere un paso más que "if([bool])"?

simplify calculator boolean

Question

Esta es una pregunta puramente pedante, para saciar mi propia curiosidad.

Tiendo a ir con la última opción en la pregunta (entonces: if (boolCheck) { ... } ), mientras que un compañero de trabajo siempre escribe el primero ( if (boolCheck == true) { ... } ). Siempre me burlé de él al respecto, y él siempre lo explicó como un viejo hábito desde la primera vez que comenzó a programar.

Pero hoy se me acaba de ocurrir que realmente escribir la parte completa == true puede de hecho requerir un paso adicional para el procesamiento, ya que cualquier expresión con un operador == se evalúa a un valor booleano. ¿Es esto cierto?

En otras palabras, tal como lo entiendo, la opción sin la == línea verdadera podría describirse en términos generales de la siguiente manera:

1. Verifica X

Mientras que la opción con la == línea verdadera sería más como:

1. Deje que Y sea verdadero si X es verdadero, de lo contrario falso
2. Verifique Y

¿Estoy en lo correcto? ¿O quizás cualquier compilador / intérprete normal eliminará esta diferencia? ¿O estoy pasando por alto algo, y realmente no hay diferencia en absoluto?

Obviamente, no habrá diferencia en términos de rendimiento observado real. Como dije, solo tengo curiosidad.

EDITAR: Gracias a todos los que publicaron resultados compilados para ilustrar si los pasos fueron diferentes entre los dos enfoques. (Parece que la mayoría de las veces lo fueron, aunque solo ligeramente).

Solo quiero reiterar que no estaba preguntando cuál es el enfoque "correcto". Entiendo que muchas personas favorecen una sobre la otra. También entiendo que, lógicamente, los dos son idénticos. Solo tenía curiosidad si las operaciones reales que realiza la CPU son exactamente las mismas para ambos métodos; como resulta, la mayor parte del tiempo (obviamente depende del lenguaje, compilador, etc.), no lo son.

Answer 1

Aquí está el desmontaje de Python (2.6):

>>> def check(x): return (bool(x) == True)
>>> import dis
>>> dis.dis(check)
1 0 LOAD_GLOBAL 0 (bool)
3 LOAD_FAST 0 (x)
6 CALL_FUNCTION 1
9 LOAD_GLOBAL 1 (True)
12 COMPARE_OP 2 (==)
15 RETURN_VALUE
>>> def check2(x): return bool(x)
>>> dis.dis(check2)
1 0 LOAD_GLOBAL 0 (bool)
3 LOAD_FAST 0 (x)
6 CALL_FUNCTION 1
9 RETURN_VALUE

Supongo que la check la razón no está optimizada debido a que Python es un lenguaje dinámico. Esto en sí mismo no significa que Python use un compilador deficiente, pero podría hacer una pequeña inferencia de tipo aquí. ¿Tal vez hace una diferencia cuando se crea un archivo .pyd?

Answer 2

Creo que la comparación con verdadero muestra una falta de comprensión por parte de tu compañero. Los bools se deben nombrar cosas para evitar esto (como isAvaliable : if (isAvailable) {...} ).

Answer 3

Depende del compilador. Puede haber optimizaciones para cualquier caso.

Answer 4

El compilador MSVC ++ 6.0 genera código ligeramente diferente para las dos formas:

4: if ( ok ) {
00401033 mov eax,dword ptr [ebp-8]
00401036 and eax,0FFh
0040103B test eax,eax
0040103D je main+36h (00401046)
....
7: if ( ok == true ) {
00401046 mov ecx,dword ptr [ebp-8]
00401049 and ecx,0FFh
0040104F cmp ecx,1
00401052 jne main+4Bh (0040105b)

La versión anterior debería ser muy ligeramente más rápida, si recuerdo correctamente mis tiempos 8086 :-)

Answer 5

El compilador debería generar el mismo código. Sin embargo, comparar con verdadero es posiblemente mejor porque es más explícito. En general, no hago una comparación explícita, pero no debes burlarte de él por hacerlo.

Editar: la forma más fácil de decir es intentarlo. El compilador de MS (cl.exe) genera la misma cantidad de pasos en el ensamblado:

int _tmain(int argc, _TCHAR* argv[])
{
bool test_me = true;
if (test_me) {
004113C2 movzx eax,byte ptr [test_me]
004113C6 test eax,eax
004113C8 je wmain+41h (4113E1h)
printf("test_me was true!");
}
if (test_me == true) {
004113E1 movzx eax,byte ptr [test_me]
004113E5 cmp eax,1
004113E8 jne wmain+61h (411401h)
printf("still true!");
}
return 0;
}

En este punto, la pregunta es ¿do test y cmp tienen el mismo costo? Supongo que sí, aunque los expertos pueden señalar las diferencias.

El resultado práctico es que no debes preocuparte por esto. Lo más probable es que tenga peces de mayor rendimiento para freír.

Answer 6

En mi experiencia if (flag==true) es una mala práctica.

El primer argumento es académico:

Si tiene una bool flag , es true o false .

Ahora, la expresión

(flag==true)

nuevamente, es true o false , no es más expresivo, solo redundante, la flag no puede ser "más verdadera" o "más falsa" de lo que ya es. Sería "más claro" solo si no es obvio que la flag es booleana, pero hay una forma estándar de arreglar eso que funciona para todos los tipos: elija un nombre mejor .

Extendiendo esto más allá de lo razonable, lo siguiente sería "incluso mejor":

((flag==true)==true)

El segundo argumento es pragmático y específico de la plataforma

C y las primeras implementaciones de C ++ no tenían un tipo real de "bool", por lo que existen diferentes convenciones para las banderas, siendo las más comunes las que no son cero. No es raro que las API devuelvan un tipo BOOL basado en enteros, pero no apliquen el valor de retorno para que sea 0 o 1.

Algunos entornos usan las siguientes definiciones:

#define FALSE 0
#define TRUE (!FALSE)

buena suerte con if ((1==1) == TRUE)

Además, algunas plataformas usan valores diferentes, por ejemplo, el VARIANT_BOOL para la interoperabilidad de VB es short , y VARIANT_TRUE es -1 .

Al mezclar bibliotecas usando estas definiciones, una comparación explícita a verdadera puede ser fácilmente un error disfrazado de buenas intenciones. Entonces, no lo hagas

Answer 7

En mi humilde opinión, es una mala idea usar el if (boolCheck == true) , por una simple razón: si accidentalmente escribe un solo signo ''igual'' en lugar de un doble (es decir, if (boolCheck = true) ), asignará true boolCheck y siempre volverá verdadero, lo que obviamente sería un error. Por supuesto, la mayoría de los compiladores modernos mostrarán una advertencia cuando lo vean (al menos el compilador de C # lo hace), pero muchos desarrolladores simplemente ignoran las advertencias ...

Si quiere ser explícito, debería preferir este formulario: if (true == boolCheck) . Esto evitará la asignación accidental de la variable, y causará un error de compilación si olvida un signo ''igual''.

Answer 8

Esperaría que la diferencia fuera optimizada por cualquier compilador medio decente.

(Acabo de verificar con C # y el código compilado es exactamente el mismo para ambas sintaxis).

Answer 9

Esto se aplica a los idiomas específicos y a lo que consideran valores "verídicos". Aquí hay dos más comunes: JavaScript y PHP .

El operador triple equal en ambos idiomas asegura que realmente está buscando un tipo de verdad booleano. Por ejemplo, en PHP, verificar if ($value) puede ser diferente de if ($value==true) o if ($value===true) :

$f = true;
$z = 1;
$n = null;
$a = array(1,2);
print ($f) ?''true'':''false''; // true
print ($f==true) ?''true'':''false''; // true
print ($f===true) ?''true'':''false''; // true
print "/n";
print ($z) ?''true'':''false''; // true
print ($z==true) ?''true'':''false''; // true
print ($z===true) ?''true'':''false''; // false
print "/n";
print ($n) ?''true'':''false''; // false
print ($n==true) ?''true'':''false''; // false
print ($n===true) ?''true'':''false''; // false
print "/n";
print ($a) ?''true'':''false''; // true
print ($a==true) ?''true'':''false''; // true
print ($a===true) ?''true'':''false''; // false
print "/n";
print "/n";

Espero que los idiomas que uno habla diariamente informen cómo uno ve esta pregunta.

Answer 10

No existe una diferencia lógica, suponiendo que no se está produciendo el encasillado interno, por ejemplo, probando fstream.

ifstream fin;
...
if( ! fin)
...

Answer 11

Pregunta duplicada ( ¿Debo usar `! IsGood` o` IsGood == false`? ). Aquí hay un puntero a mi respuesta anterior:

La técnica de probar específicamente contra verdadero o falso es una mala práctica si se supone que la variable en cuestión se debe usar como un valor booleano (incluso si su tipo no es booleano), especialmente en C / C ++. Las pruebas en contra de la verdad pueden (y probablemente lo harán) conducir a errores sutiles.

Vea la siguiente respuesta SO para más detalles:

¿Debo usar `! IsGood` o` IsGood == false`?

Aquí hay un hilo que detalla el razonamiento detrás de por qué "== verdadero" a menudo es falso en un detalle más explícito, incluida la explicación de Stroustrup: https://qt-project.org/forums/viewthread/32642

Answer 12

Probar la igualdad en true puede conducir a un error, al menos en C: en C, ''if'' se puede usar en tipos enteros (no solo en tipos booleanos) y aceptar cualquier valor distinto de cero; sin embargo, el símbolo ''VERDADERO'' es un valor específico distinto de cero (por ejemplo, 1 ). Esto puede volverse importante con bit-flags:

if (flags & DCDBIT)
{
//do something when the DCDBIT bit is set in the flags variable
}

Entonces, dado una función como esta ...

int isDcdSet()
{
return (flags & DCDBIT);
}

... la expresión "if (isDcdSet ())" no es lo mismo que "if (isDcdSet () == TRUE)".

De todas formas; Creo que un compilador de optimización debería optimizar cualquier diferencia (porque no hay diferencia lógica), suponiendo que es un lenguaje con un tipo booleano verdadero (no solo entero).

Answer 13

Puede haber alguna justificación en la sintaxis "boolCheck == true" dependiendo del nombre de la variable que está probando.

Por ejemplo, si el nombre de la variable era "estado", entonces puede tener:

if (state) {
...
}

o puedes tener

if (state == true) {
...
}

En este caso, creo que la última forma es más clara y más obvia.

Otro ejemplo sería una variable como "habilitado", en cuyo caso la primera forma es más clara.

Ahora tener una variable booleana llamada "estado" es una mala práctica, pero puede que no tenga control sobre eso, en cuyo caso la sintaxis "== true" puede mejorar la legibilidad del código.

Answer 14

Puede que no sea lo mismo si está trabajando con un Bool Nullable.

Ejemplo:

Bool? myBool = true
if(myBool) // This will not compile
if(myBool == true) //this will compile