¿Por qué es imposible construir un compilador que pueda determinar si una función de C ++ cambiará el valor de una variable en particular?

Leí esta línea en un libro:

Probablemente es imposible construir un compilador que realmente pueda determinar si una función de C ++ cambiará o no el valor de una variable en particular.

El párrafo hablaba de por qué el compilador es conservador al verificar la consistencia.

¿Por qué es imposible construir tal compilador?

El compilador siempre puede comprobar si se reasigna una variable, si se invoca una función no constante en ella o si se pasa como un parámetro no constante ...

¿Por qué es imposible construir tal compilador?

Por la misma razón que no puede escribir un programa que determine si un programa dado terminará. Esto se conoce como el problema de la detención y es una de esas cosas que no se pueden calcular.

Para ser claros, puede escribir un compilador que pueda determinar que una función cambia la variable en algunos casos , pero no puede escribir uno que le diga de manera confiable que la función cambiará o no la variable (o se detendrá) por todas las funciones posibles.

Aquí tienes un ejemplo sencillo:

void foo() {
    if (bar() == 0) this->a = 1;
}

¿Cómo puede un compilador determinar, con solo mirar ese código, si fooalguna vez cambiará a? Si lo hace o no depende de condiciones externas a la función, es decir, la implementación de bar. Hay más que eso en la prueba de que el problema de la detención no es computable, pero ya está bien explicado en el artículo de Wikipedia vinculado (y en todos los libros de texto de teoría de la computación), así que no intentaré explicarlo correctamente aquí.

Imagínese que tal compilador existe. Supongamos también que, por conveniencia, proporciona una función de biblioteca que devuelve 1 si la función pasada modifica una variable dada y 0 cuando la función no lo hace. Entonces, ¿qué debería imprimir este programa?

int variable = 0;

void f() {
    if (modifies_variable(f, variable)) {
        /* do nothing */
    } else {
        /* modify variable */
        variable = 1;
    }
}

int main(int argc, char **argv) {
    if (modifies_variable(f, variable)) {
        printf("Modifies variable\n");
    } else {
        printf("Does not modify variable\n");
    }

    return 0;
}

No confunda "modificará o no una variable dadas estas entradas" porque "tiene una ruta de ejecución que modifica una variable".

El primero se denomina determinación de predicado opaco y es trivialmente imposible de decidir; aparte de la reducción del problema de la detención, puede señalar que las entradas pueden provenir de una fuente desconocida (por ejemplo, el usuario). Esto es cierto para todos los lenguajes, no solo C ++.

Sin embargo, la última declaración se puede determinar mirando el árbol de análisis, que es algo que hacen todos los compiladores de optimización. La razón por la que lo hacen es que las funciones puras (y las funciones referencialmente transparentes , para alguna definición de referencialmente transparente ) tienen todo tipo de optimizaciones agradables que se pueden aplicar, como ser fácilmente insertables o tener sus valores determinados en tiempo de compilación; pero para saber si una función es pura, necesitamos saber si alguna vez podrá modificar una variable.

Entonces, lo que parece ser una declaración sorprendente sobre C ++ es en realidad una declaración trivial sobre todos los lenguajes.

Creo que la palabra clave en "si una función de C ++ cambiará o no el valor de una variable en particular" es "voluntad". Ciertamente es posible construir un compilador que verifique si una función de C ++ puede cambiar el valor de una variable en particular, no se puede decir con certeza que el cambio va a ocurrir:

void maybe(int& val) {
    cout << "Should I change value? [Y/N] >";
    string reply;
    cin >> reply;
    if (reply == "Y") {
        val = 42;
    }
}

No creo que sea necesario invocar el problema de la detención para explicar que no se puede saber algorítmicamente en el momento de la compilación si una función determinada modificará una determinada variable o no.

En cambio, es suficiente señalar que el comportamiento de una función a menudo depende de las condiciones de tiempo de ejecución, que el compilador no puede conocer de antemano. P.ej

int y;

int main(int argc, char *argv[]) {
   if (argc > 2) y++;
}

¿Cómo podría el compilador predecir con certeza si yse modificará?

Se puede hacer y los compiladores lo hacen todo el tiempo para algunas funciones , esto es, por ejemplo, una optimización trivial para accesos en línea simples o muchas funciones puras.

Lo que es imposible es conocerlo en el caso general.

Siempre que haya una llamada al sistema o una llamada a una función proveniente de otro módulo, o una llamada a un método potencialmente anulado, cualquier cosa podría suceder, incluida la toma de control hostil por el uso de un hacker de un desbordamiento de pila para cambiar una variable no relacionada.

Sin embargo, debe usar const, evitar globales, preferir referencias a punteros, evitar reutilizar variables para tareas no relacionadas, etc., lo que facilitará la vida del compilador al realizar optimizaciones agresivas.

Hay varias vías para explicar esto, una de las cuales es el problema de detención :

En la teoría de la computabilidad, el problema de la detención se puede plantear de la siguiente manera: "Dada una descripción de un programa de computadora arbitrario, decida si el programa termina de ejecutarse o continúa ejecutándose para siempre". Esto es equivalente al problema de decidir, dado un programa y una entrada, si el programa finalmente se detendrá cuando se ejecute con esa entrada o si se ejecutará para siempre.

Alan Turing demostró en 1936 que no puede existir un algoritmo general para resolver el problema de detención para todos los posibles pares de entrada de programa.

Si escribo un programa que se parece a esto:

do tons of complex stuff
if (condition on result of complex stuff)
{
    change value of x
}
else
{
    do not change value of x
}

¿El valor del xcambio? Para determinar esto, primero tendría que determinar si la do tons of complex stuffpieza provoca que se active la condición o, lo que es más básico, si se detiene. Eso es algo que el compilador no puede hacer.

¡Realmente sorprendido de que no haya una respuesta que usar el problema de la detención directamente! Hay una reducción muy sencilla de este problema al problema de la detención.

Imagine que el compilador pudiera decir si una función cambió o no el valor de una variable. Entonces ciertamente podría decir si la siguiente función cambia el valor de y o no, asumiendo que el valor de x se puede rastrear en todas las llamadas durante el resto del programa:

foo(int x){
   if(x)
       y=1;
}

Ahora, para cualquier programa que nos guste, vamos a reescribirlo como:

int y;
main(){
    int x;
    ...
    run the program normally
    ...
    foo(x);
}

Observe que, si, y solo si, nuestro programa cambia el valor de y, entonces termina - foo () es lo último que hace antes de salir. ¡Esto significa que hemos resuelto el problema de la detención!

Lo que nos muestra la reducción anterior es que el problema de determinar si el valor de una variable cambia es al menos tan difícil como el problema de la detención. Se sabe que el problema de la detención es incomputable, por lo que este también debe serlo.

Tan pronto como una función llama a otra función de la que el compilador no "ve" la fuente, debe asumir que la variable ha cambiado o las cosas pueden ir mal más adelante. Por ejemplo, digamos que tenemos esto en "foo.cpp":

 void foo(int& x)
 {
    ifstream f("f.dat", ifstream::binary);
    f.read((char *)&x, sizeof(x));
 }

y tenemos esto en "bar.cpp":

void bar(int& x)
{
  foo(x);
}

¿Cómo puede el compilador "saber" que xno está cambiando (o ESTÁ cambiando, más apropiadamente) bar?

Estoy seguro de que podemos llegar a algo más complejo, si esto no es lo suficientemente complejo.

Es imposible, en general, para el compilador para determinar si la variable se puede cambiar, ya que se han señalado.

Al verificar la constancia, la pregunta de interés parece ser si la variable puede ser cambiada por una función. Incluso esto es difícil en idiomas que admiten punteros. No puede controlar lo que hace otro código con un puntero, incluso podría leerse desde una fuente externa (aunque es poco probable). En lenguajes que restringen el acceso a la memoria, este tipo de garantías pueden ser posibles y permiten una optimización más agresiva que C ++.

Para hacer la pregunta más específica, sugiero que el siguiente conjunto de restricciones puede haber sido lo que el autor del libro pudo haber tenido en mente:

1. Suponga que el compilador está examinando el comportamiento de una función específica con respecto a la constancia de una variable. Para que sea correcto, un compilador tendría que asumir (debido al aliasing como se explica a continuación) si la función llama a otra función, la variable cambia, por lo que el supuesto n. ° 1 solo se aplica a fragmentos de código que no realizan llamadas a funciones.
2. Suponga que la variable no es modificada por una actividad concurrente o asincrónica.
3. Suponga que el compilador solo determina si la variable se puede modificar, no si se modificará. En otras palabras, el compilador solo realiza análisis estático.
4. Suponga que el compilador solo está considerando el código que funciona correctamente (sin considerar los excesos / insuficiencias de la matriz, los punteros incorrectos, etc.)

En el contexto del diseño del compilador, creo que las suposiciones 1, 3, 4 tienen perfecto sentido en la vista de un escritor de compiladores en el contexto de la corrección de generación de código y / o la optimización de código. El supuesto 2 tiene sentido en ausencia de la palabra clave volátil. Y estas suposiciones también enfocan la pregunta lo suficiente como para hacer que juzgar una respuesta propuesta sea mucho más definitiva :-)

Dadas esas suposiciones, una razón clave por la que no se puede suponer la const-ness se debe al aliasing variable. El compilador no puede saber si otra variable apunta a la variable const. La creación de alias podría deberse a otra función en la misma unidad de compilación, en cuyo caso el compilador podría buscar entre funciones y usar un árbol de llamadas para determinar estáticamente que podría producirse la creación de alias. Pero si el alias se debe a una biblioteca u otro código externo, entonces el compilador no tiene forma de saber al ingresar la función si las variables tienen alias.

Se podría argumentar que si una variable / argumento está marcado como constante, no debería estar sujeto a cambios mediante alias, pero para un escritor de compiladores eso es bastante arriesgado. Incluso puede ser arriesgado para un programador humano declarar una variable const como parte de, digamos, un gran proyecto en el que no conoce el comportamiento de todo el sistema, o el sistema operativo, o una biblioteca, para saber realmente que una variable ganó ' t cambiar.

Incluso si se declara una variable const, no significa que un código mal escrito pueda sobrescribirla.

//   g++ -o foo foo.cc

#include <iostream>
void const_func(const int&a, int* b)
{
   b[0] = 2;
   b[1] = 2;
}

int main() {
   int a = 1;
   int b = 3;

   std::cout << a << std::endl;
   const_func(a,&b);
   std::cout << a << std::endl;
}

salida:

1
2

Para ampliar mis comentarios, el texto de ese libro no está claro, lo que confunde el problema.

Como comenté, ese libro está tratando de decir: "Consigamos un número infinito de monos para escribir todas las funciones concebibles de C ++ que se puedan escribir. Habrá casos en los que si elegimos una variable que (alguna función particular que escribieron los monos) utiliza, no podemos determinar si la función cambiará esa variable ".

Por supuesto, para algunas (incluso muchas) funciones en cualquier aplicación, esto puede ser determinado por el compilador y muy fácilmente. Pero no para todos (o necesariamente para la mayoría).

Esta función se puede analizar fácilmente:

static int global;

void foo()
{
}

"foo" claramente no modifica "global". No modifica nada en absoluto, y un compilador puede resolver esto muy fácilmente.

Esta función no se puede analizar así:

static int global;

int foo()
{
    if ((rand() % 100) > 50)
    {
        global = 1;
    }
    return 1;

Dado que las acciones de "foo" dependen de un valor que puede cambiar en tiempo de ejecución , es evidente que no se puede determinar en tiempo de compilación. si modificará "global".

Todo este concepto es mucho más sencillo de entender de lo que los científicos informáticos creen. Si la función puede hacer algo diferente en función de las cosas que pueden cambiar en tiempo de ejecución, entonces no puede averiguar qué hará hasta que se ejecute, y cada vez que se ejecute puede hacer algo diferente. Ya sea demostrablemente imposible o no, obviamente es imposible.