Perché è impossibile creare un compilatore in grado di determinare se una funzione C ++ cambierà il valore di una particolare variabile?

Ho letto questa riga in un libro:

È dimostrato che è impossibile costruire un compilatore che possa effettivamente determinare se una funzione C ++ cambierà o meno il valore di una particolare variabile.

Il paragrafo parlava del motivo per cui il compilatore è conservatore quando controlla const-ness.

Perché è impossibile costruire un tale compilatore?

Il compilatore può sempre controllare se una variabile viene riassegnata, una funzione non const viene invocata su di essa o se viene passata come parametro non const ...

Perché è impossibile costruire un tale compilatore?

Per lo stesso motivo per cui non è possibile scrivere un programma che determinerà se un determinato programma verrà terminato. Questo è noto come il problema dell'arresto ed è una di quelle cose che non è calcolabile.

Per essere chiari, puoi scrivere un compilatore che possa determinare che una funzione cambia la variabile in alcuni casi , ma non puoi scriverne uno che ti dica in modo affidabile che la funzione cambierà o non cambierà la variabile (o si fermerà) per ogni possibile funzione.

Ecco un semplice esempio:

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

Come può un compilatore determinare, solo guardando quel codice, se foocambierà mai a? Che lo faccia o no dipende da condizioni esterne alla funzione, vale a dire l'implementazione di bar. C'è molto di più nella prova che il problema dell'arresto non è calcolabile, ma è già ben spiegato nell'articolo di Wikipedia collegato (e in ogni libro di testo di teoria del calcolo), quindi non cercherò di spiegarlo correttamente qui.

Immagina che esista un tale compilatore. Supponiamo anche che per comodità fornisca una funzione di libreria che restituisce 1 se la funzione passata modifica una data variabile e 0 quando la funzione non lo fa. Allora cosa dovrebbe stampare questo programma?

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;
}

Non confondere "modificherà o non modificherà una variabile dati questi input" perché "ha un percorso di esecuzione che modifica una variabile".

Il primo è chiamato determinazione del predicato opaco ed è banalmente impossibile da decidere: a parte la riduzione del problema dell'arresto, potresti semplicemente sottolineare che gli input potrebbero provenire da una fonte sconosciuta (ad es. L'utente). Questo è vero per tutti i linguaggi, non solo per il C ++.

Quest'ultima affermazione, tuttavia, può essere determinata guardando l'albero di analisi, che è qualcosa che fanno tutti i compilatori di ottimizzazione. Il motivo per cui lo fanno è che le funzioni pure (e le funzioni referenzialmente trasparenti , per qualche definizione di referenzialmente trasparente ) hanno tutti i tipi di belle ottimizzazioni che possono essere applicate, come essere facilmente inlinabili o avere i loro valori determinati in fase di compilazione; ma per sapere se una funzione è pura, dobbiamo sapere se può mai modificare una variabile.

Quindi, quella che sembra essere un'affermazione sorprendente sul C ++ è in realtà un'affermazione banale su tutti i linguaggi.

Penso che la parola chiave in "se una funzione C ++ cambierà o meno il valore di una particolare variabile" è "volontà". È certamente possibile costruire un compilatore che controlli se una funzione C ++ è autorizzata o meno a modificare il valore di una particolare variabile, non si può dire con certezza che il cambiamento avverrà:

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

Non penso sia necessario invocare il problema dell'arresto per spiegare che non è possibile sapere algoritmicamente in fase di compilazione se una data funzione modificherà o meno una determinata variabile.

È invece sufficiente sottolineare che il comportamento di una funzione dipende spesso dalle condizioni di runtime, che il compilatore non può conoscere in anticipo. Per esempio

int y;

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

Come potrebbe il compilatore prevedere con certezza se yverrà modificato?

Può essere fatto ei compilatori lo fanno continuamente per alcune funzioni , questa è ad esempio una banale ottimizzazione per semplici funzioni di accesso in linea o molte funzioni pure.

Ciò che è impossibile è saperlo nel caso generale.

Ogni volta che c'è una chiamata di sistema o una chiamata di funzione proveniente da un altro modulo, o una chiamata a un metodo potenzialmente sovrascritto, potrebbe accadere qualsiasi cosa, inclusa l'acquisizione ostile dall'uso di uno stack overflow da parte di alcuni hacker per modificare una variabile non correlata.

Tuttavia dovresti usare const, evitare le globali, preferire i riferimenti ai puntatori, evitare di riutilizzare le variabili per attività non correlate, ecc. Che renderà più facile la vita del compilatore quando si eseguono ottimizzazioni aggressive.

Ci sono molti modi per spiegarlo, uno dei quali è il problema dell'arresto :

Nella teoria della computabilità, il problema dell'arresto può essere affermato come segue: "Data una descrizione di un programma per computer arbitrario, decidere se il programma termina l'esecuzione o continua a funzionare all'infinito". Ciò equivale al problema di decidere, dato un programma e un input, se il programma alla fine si fermerà quando viene eseguito con quell'input o se verrà eseguito per sempre.

Alan Turing ha dimostrato nel 1936 che non può esistere un algoritmo generale per risolvere il problema dell'arresto per tutte le possibili coppie di input di programma.

Se scrivo un programma simile a questo:

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

Il valore del xcambiamento? Per determinarlo, dovresti prima determinare se la do tons of complex stuffparte causa l' attivazione della condizione o, ancora più semplice, se si arresta. È qualcosa che il compilatore non può fare.

Davvero sorpreso che non ci sia una risposta che usi direttamente il problema dell'arresto! C'è una riduzione molto diretta da questo problema al problema dell'arresto.

Immagina che il compilatore possa dire se una funzione ha cambiato o meno il valore di una variabile. Quindi sarebbe sicuramente in grado di dire se la seguente funzione cambia il valore di y oppure no, assumendo che il valore di x possa essere tracciato in tutte le chiamate durante il resto del programma:

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

Ora, per qualsiasi programma che ci piace, riscriviamolo come:

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

Si noti che, se, e solo se, il nostro programma cambia il valore di y, allora termina - foo () è l'ultima cosa che fa prima di uscire. Ciò significa che abbiamo risolto il problema dell'arresto!

Ciò che la riduzione di cui sopra ci mostra è che il problema di determinare se il valore di una variabile cambia è difficile almeno quanto il problema dell'arresto. Il problema dell'arresto è noto per essere incomputabile, quindi deve esserlo anche questo.

Non appena una funzione chiama un'altra funzione di cui il compilatore non "vede" l'origine, deve presumere che la variabile sia cambiata, altrimenti le cose potrebbero andare storte più avanti. Ad esempio, supponiamo di avere questo in "foo.cpp":

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

e abbiamo questo in "bar.cpp":

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

Come può il compilatore "sapere" che xnon sta cambiando (o sta cambiando, in modo più appropriato) bar?

Sono sicuro che possiamo inventare qualcosa di più complesso, se questo non è abbastanza complesso.

In generale è impossibile per il compilatore determinare se la variabile lo farà modificata, come è stato sottolineato.

Quando si controlla const-ness, la domanda di interesse sembra essere se la variabile può essere modificata da una funzione. Anche questo è difficile nelle lingue che supportano i puntatori. Non puoi controllare cosa fa l'altro codice con un puntatore, potrebbe anche essere letto da una fonte esterna (anche se improbabile). Nei linguaggi che limitano l'accesso alla memoria, questi tipi di garanzie possono essere possibili e consentono un'ottimizzazione più aggressiva rispetto al C ++.

Per rendere la domanda più specifica, suggerisco che il seguente insieme di vincoli potrebbe essere stato ciò che l'autore del libro potrebbe aver avuto in mente:

1. Supponiamo che il compilatore stia esaminando il comportamento di una funzione specifica rispetto alla costanza di una variabile. Per correttezza, un compilatore dovrebbe assumere (a causa dell'aliasing come spiegato di seguito) se la funzione chiama un'altra funzione la variabile viene modificata, quindi l'ipotesi n. 1 si applica solo ai frammenti di codice che non effettuano chiamate di funzione.
2. Supponiamo che la variabile non venga modificata da un'attività asincrona o simultanea.
3. Supponiamo che il compilatore determini solo se la variabile può essere modificata, non se verrà modificata. In altre parole, il compilatore esegue solo l'analisi statica.
4. Supponiamo che il compilatore stia considerando solo il codice che funziona correttamente (senza considerare overrun / underrun di array, puntatori errati, ecc.)

Nel contesto della progettazione del compilatore, penso che i presupposti 1,3,4 abbiano perfettamente senso nella vista di uno scrittore di compilatori nel contesto della correttezza della generazione del codice e / o dell'ottimizzazione del codice. L'assunzione 2 ha senso in assenza della parola chiave volatile. E questi presupposti focalizzano anche la domanda abbastanza da rendere il giudizio di una risposta proposta molto più definitivo :-)

Dati questi presupposti, un motivo chiave per cui non si può presumere costanza è dovuto all'aliasing delle variabili. Il compilatore non può sapere se un'altra variabile punta alla variabile const. L'aliasing potrebbe essere dovuto a un'altra funzione nella stessa unità di compilazione, nel qual caso il compilatore potrebbe esaminare le funzioni e utilizzare un albero delle chiamate per determinare staticamente che potrebbe verificarsi l'aliasing. Ma se l'aliasing è dovuto a una libreria o altro codice esterno, il compilatore non ha modo di sapere al momento dell'ingresso nella funzione se le variabili sono alias.

Si potrebbe sostenere che se una variabile / argomento è contrassegnato come const, non dovrebbe essere soggetto a modifiche tramite aliasing, ma per uno scrittore di compilatore è piuttosto rischioso. Può anche essere rischioso per un programmatore umano dichiarare una variabile const come parte di, ad esempio, un grande progetto in cui non conosce il comportamento dell'intero sistema, o il sistema operativo, o una libreria, per conoscere davvero una variabile ha vinto ' t cambiare.

Anche se viene dichiarata una variabile const, non significa che un codice scritto male possa sovrascriverla.

//   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;
}

produzione:

1
2

Per espandere i miei commenti, il testo di quel libro non è chiaro, il che offusca il problema.

Come ho commentato, quel libro sta cercando di dire, "facciamo in modo che un numero infinito di scimmie scriva ogni funzione C ++ concepibile che potrebbe mai essere scritta. Ci saranno casi in cui se scegliamo una variabile che (una funzione particolare scritta dalle scimmie) utilizza, non possiamo capire se la funzione cambierà quella variabile. "

Ovviamente per alcune (anche molte) funzioni in una data applicazione, questo può essere determinato dal compilatore e molto facilmente. Ma non per tutti (o necessariamente per la maggior parte).

Questa funzione può essere facilmente analizzata:

static int global;

void foo()
{
}

"foo" chiaramente non modifica "globale". Non modifica assolutamente nulla e un compilatore può risolverlo molto facilmente.

Questa funzione non può essere così analizzata:

static int global;

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

Poiché le azioni di "pippo" dipendono da un valore che può cambiare in fase di esecuzione , chiaramente non puòessere determinato in fase di compilazione se modificherà "globale".

L'intero concetto è molto più semplice da capire di quanto gli scienziati informatici ritengano che sia. Se la funzione può fare qualcosa di diverso in base alle cose che possono cambiare in fase di esecuzione, allora non puoi capire cosa farà finché non viene eseguita e ogni volta che viene eseguita potrebbe fare qualcosa di diverso. Che sia provabilmente impossibile o meno, è ovviamente impossibile.