jajajajajajajajajajajajajaja Es que no debemos perder el tiempo, Frodo. XD
Bueno, aprovecho para comentar un mito que según sé es falso, pero quisiera saber si alguno de ustedes ha escuchado de él. Se dice que en las aplicaciones de VB.net cuando uno coloca un if de la forma:
If A = True And B = True Then
End If
Aunque la primera evaluación sea falsa se hace la segunda evaluación y por ello es mejor realizar un if anidado.
Yo sigo creyendo que es un mito, pero qué dicen ustedes?
No es cierto. Un código compilado que ejecutara todo el IF aunque este ya no cumpla una condición requerida sería extremadamente ineficiente. De hecho no es tan difícil programar a mano este tipo de optimización, y es más breve y hasta claro.
Por ejemplo para el código anterior sería más eficiente compilarlo así:
1. comparar A==TRUE
2. si es FALSE, terminar el IF en 6 (y no se ejecuta la siguiente condición)
3. comparar B==TRUE
4. si es FALSE, terminar el IF en 6
5. { Código dentro del IF }
6. terminar el IF
Que compilarlo así:
1. comparar A==TRUE
2. si es TRUE, seguir comparando en 3 (un salto inmediato poco inteligente)
3. comparar B==TRUE
4. si es TRUE, entrar en el IF en 6
5. ir a terminar el IF en 7
6 { Código dentro del IF }
7. terminar el IF
Son más comprobaciones ejecutadas sin razón cuando se sabe que si se usa AND y no se cumple no hay caso de seguir ejecutando, y requiere un salto incondicional como terminador del IF (en el segundo caso, que es más ineficiente). Y si el IF fuera mucho más complejo, la ejecución sería menos que óptima, y eso no sería aceptable en aplicaciones de grado industrial que tienen elementos mucho más complejos que esto.
Hablando de
C++:
En un IF con varias condiciones unidas por un AND (Ejemplo: "if(1 && 0);"), se leen en orden, y en el momento en que una sea falsa, acaba con el IF. Esto lo podemos ver fácilmente (¬¬ vagos) con un código como este:
#include <iostream>
bool asd(){
std::cout << "Hola";
return false;
}
int main () {
if(2==0 && asd());
system("pause>nul");
}
Compilado con MinGW*Haced la prueba en VB, y los lenguajes que uséis, y así tenemos este hilo para saber que lenguajes leen todas las condiciones xD
Respecto a la pregunta original, Ikillnukes, el compilador lo que hace es compilar, no averiguar si las condiciones (excepto las del tipo "#if") son o no son verdaderas.
Eso depende de la comprobación y de la forma en la que se optimiza el código. Si por ejemplo hay valores constantes que siempre van a evaluar a verdadero o a falso, el compilador haría bien en eliminarlos, entre otras optimizaciones más complejas. Tener que comprobar todas las condiciones determinables en tiempo de compilación debería ser una optimización básica. También es necesario realizar otras comprobaciones para las demás optimizaciones y para eso se necesita algún nivel de evaluación del IF (el simple hecho de tener que compilarlo requiere eso).