bien, estoy un poco avergonzado de hacer esta pregunta, pero sólo quiero estar seguro ...cortocircuito de evaluación y los efectos secundarios
Se sabe que C utiliza evaluación de cortocircuito en las expresiones booleanas:
int c = 0;
if (c && func(c)) { /* whatever... */ }
En ese ejemplo func(c) no se llama porque c evalúa a 0. Pero, ¿qué tal un ejemplo más sofisticado en el que los efectos secundarios de la comparación cambiarían la variable que se compara a continuación? De esta manera:
int c; /* this is not even initialized... */
if (canInitWithSomeValue(&c) && c == SOMETHING) { /*...*/ }
Función canInitWithSomeValue vuelve verdadera y cambios en el valor del puntero, dados en caso de éxito. ¿Está garantizado que las comparaciones posteriores (c == SOMETHING en este ejemplo) utilizan el valor establecido por canInitWithSomeValue(&c)?
No importa qué tan pesadas optimizaciones utiliza el compilador?
Creo que puede confundir la evaluación de cortocircuito y la optimización del compilador. En el primer ejemplo, el compilador optimizará toda esa declaración 'if', porque nunca se puede ejecutar. La evaluación de cortocircuito significaría que si tuviera 'if (func1() && func2()) {...}', y func1() evaluado a falso ** en tiempo de ejecución ** (es decir, no definidamente al compilar), entonces el código no debería verificar 'func2()' - el compilador debería haber creado el código máquina de modo que si 'func1()' es falso, 'func2()' no se llama. – Stephen
Que 'int c = 0' estaba allí para indicar que' c' es igual a '0' en el momento de la comparación, me doy cuenta de que en un caso así de simple el compilador optimizaría todo el' if'. –
Ah, me disculpo. Te malinterpreté Mis disculpas. – Stephen