Warum ist es unmöglich, einen Compiler zu erstellen, der bestimmen kann, ob eine C ++ - Funktion den Wert einer bestimmten Variablen ändert?

Ich habe diese Zeile in einem Buch gelesen:

Es ist nachweislich unmöglich, einen Compiler zu erstellen, der tatsächlich bestimmen kann, ob eine C ++ - Funktion den Wert einer bestimmten Variablen ändert oder nicht.

In dem Absatz wurde darüber gesprochen, warum der Compiler bei der Überprüfung der Konstanz konservativ ist.

Warum ist es unmöglich, einen solchen Compiler zu erstellen?

Der Compiler kann jederzeit überprüfen, ob eine Variable neu zugewiesen wird, eine Nicht-Konstanten-Funktion darauf aufgerufen wird oder ob sie als Nicht-Konstanten-Parameter übergeben wird ...

Warum ist es unmöglich, einen solchen Compiler zu erstellen?

Aus dem gleichen Grund, aus dem Sie kein Programm schreiben können, das bestimmt, ob ein bestimmtes Programm beendet wird. Dies ist als Stoppproblem bekannt und eines der Dinge, die nicht berechenbar sind.

Um klar zu sein, können Sie einen Compiler schreiben, der bestimmen kann, dass eine Funktion die Variable in einigen Fällen ändert , aber Sie können keinen schreiben, der Ihnen zuverlässig sagt, dass die Funktion die Variable (oder den Halt) für ändern wird oder nicht jede mögliche Funktion.

Hier ist ein einfaches Beispiel:

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

Wie kann ein Compiler anhand des Codes feststellen, ob foosich dies jemals ändern wird a? Ob dies der Fall ist oder nicht, hängt von den Bedingungen außerhalb der Funktion ab, nämlich der Implementierung von bar. Der Beweis, dass das Problem des Anhaltens nicht berechenbar ist, ist mehr als das, aber es wird bereits im verlinkten Wikipedia-Artikel (und in jedem Lehrbuch zur Berechnungstheorie) ausführlich erklärt, sodass ich hier nicht versuchen werde, es richtig zu erklären.

Stellen Sie sich vor, ein solcher Compiler existiert. Nehmen wir außerdem an, dass der Einfachheit halber eine Bibliotheksfunktion bereitgestellt wird, die 1 zurückgibt, wenn die übergebene Funktion eine bestimmte Variable ändert, und 0, wenn die Funktion dies nicht tut. Was soll dieses Programm dann drucken?

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

Verwechseln Sie nicht "wird oder wird eine Variable nicht ändern, wenn diese Eingaben gegeben sind" für "hat einen Ausführungspfad, der eine Variable modifiziert".

Ersteres wird als undurchsichtige Prädikatenbestimmung bezeichnet und ist trivial unmöglich zu entscheiden. Abgesehen von der Reduzierung des Stoppproblems können Sie nur darauf hinweisen, dass die Eingaben möglicherweise von einer unbekannten Quelle stammen (z. B. vom Benutzer). Dies gilt für alle Sprachen, nicht nur für C ++.

Die letztere Aussage kann jedoch durch Betrachten des Analysebaums bestimmt werden, was alle optimierenden Compiler tun. Der Grund dafür ist, dass reine Funktionen (und referenziell transparente Funktionen, für eine Definition von referenziell transparent ) alle möglichen netten Optimierungen aufweisen, die angewendet werden können, z. B. leicht inlinierbar zu sein oder ihre Werte zur Kompilierungszeit bestimmen zu lassen. aber wissen , ob eine Funktion rein ist, müssen wir wissen , ob es kann immer eine Variable ändern.

Was also als überraschende Aussage über C ++ erscheint, ist eigentlich eine triviale Aussage über alle Sprachen.

Ich denke, das Schlüsselwort in "ob eine C ++ - Funktion den Wert einer bestimmten Variablen ändert oder nicht" ist "wird". Es ist sicherlich möglich, einen Compiler zu erstellen, der prüft, ob eine C ++ - Funktion den Wert einer bestimmten Variablen ändern darf oder nicht. Sie können nicht mit Sicherheit sagen, dass die Änderung stattfinden wird:

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

Ich denke nicht, dass es notwendig ist, das Stoppproblem aufzurufen, um zu erklären, dass Sie zur Kompilierungszeit nicht algorithmisch wissen können, ob eine bestimmte Funktion eine bestimmte Variable ändert oder nicht.

Stattdessen reicht es aus, darauf hinzuweisen, dass das Verhalten einer Funktion häufig von Laufzeitbedingungen abhängt, die der Compiler nicht im Voraus kennen kann. Z.B

int y;

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

Wie kann der Compiler mit Sicherheit vorhersagen, ob yÄnderungen vorgenommen werden?

Dies ist möglich und Compiler tun dies für einige Funktionen ständig. Dies ist beispielsweise eine triviale Optimierung für einfache Inline-Accessoren oder viele reine Funktionen.

Was unmöglich ist, ist es im allgemeinen Fall zu wissen.

Immer wenn ein Systemaufruf oder ein Funktionsaufruf von einem anderen Modul oder eine möglicherweise überschriebene Methode aufgerufen wird, kann alles passieren, einschließlich der feindlichen Übernahme durch die Verwendung eines Stapelüberlaufs durch einen Hacker zum Ändern einer nicht verwandten Variablen.

Sie sollten jedoch const verwenden, Globals vermeiden, Verweise auf Zeiger bevorzugen, die Wiederverwendung von Variablen für nicht verwandte Aufgaben usw. vermeiden, um das Leben des Compilers bei aggressiven Optimierungen zu vereinfachen.

Es gibt mehrere Möglichkeiten, dies zu erklären, von denen eine das Halteproblem ist :

In der Berechenbarkeitstheorie kann das Stoppproblem wie folgt angegeben werden: "Entscheiden Sie anhand einer Beschreibung eines beliebigen Computerprogramms, ob das Programm beendet wird oder für immer weiter ausgeführt wird." Dies entspricht dem Problem, bei einem Programm und einer Eingabe zu entscheiden, ob das Programm schließlich angehalten wird, wenn es mit dieser Eingabe ausgeführt wird, oder für immer ausgeführt wird.

Alan Turing bewies 1936, dass ein allgemeiner Algorithmus zur Lösung des Halteproblems für alle möglichen Programm-Eingabe-Paare nicht existieren kann.

Wenn ich ein Programm schreibe, das so aussieht:

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

Ändert sich der Wert von x? Um dies festzustellen, müssten Sie zuerst feststellen, ob das do tons of complex stuffTeil den Zustand auslöst - oder noch grundlegender, ob es anhält. Das kann der Compiler nicht.

Wirklich überrascht, dass es keine Antwort gibt, die das Stoppproblem direkt nutzt! Es gibt eine sehr einfache Reduzierung von diesem Problem auf das Stoppproblem.

Stellen Sie sich vor, der Compiler könnte feststellen, ob eine Funktion den Wert einer Variablen geändert hat oder nicht. Dann wäre es sicherlich möglich zu erkennen, ob die folgende Funktion den Wert von y ändert oder nicht, vorausgesetzt, der Wert von x kann in allen Aufrufen im Rest des Programms verfolgt werden:

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

Schreiben wir es für jedes Programm, das wir mögen, wie folgt um:

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

Beachten Sie, dass unser Programm, wenn und nur wenn es den Wert von y ändert, beendet wird - foo () ist das Letzte, was es vor dem Beenden tut. Das heißt, wir haben das Halteproblem gelöst!

Die obige Reduzierung zeigt uns, dass das Problem, festzustellen, ob sich der Wert einer Variablen ändert, mindestens so schwer ist wie das Stoppproblem. Es ist bekannt, dass das Stoppproblem inkompatibel ist, daher muss dies auch sein.

Sobald eine Funktion eine andere Funktion aufruft, deren Quelle der Compiler nicht "sieht", muss er entweder davon ausgehen, dass die Variable geändert wurde, oder es kann weiter unten ein Fehler auftreten. Angenommen, wir haben dies in "foo.cpp":

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

und wir haben dies in "bar.cpp":

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

Wie kann der Compiler "wissen", dass xsich nichts ändert (oder sich angemessener ändert) bar?

Ich bin sicher, wir können uns etwas Komplexeres einfallen lassen, wenn dies nicht komplex genug ist.

Es ist unmöglich , im Allgemeinen für die Compiler , um zu bestimmen , ob die Variable wird geändert werden, wurde als hingewiesen.

Wenn const-ness Überprüfung, scheint die Frage von Interesse zu sein , wenn die Variable kann durch eine Funktion geändert werden. Auch dies ist in Sprachen, die Zeiger unterstützen, schwierig. Sie können nicht steuern, was anderer Code mit einem Zeiger macht. Er kann sogar von einer externen Quelle gelesen werden (obwohl dies unwahrscheinlich ist). In Sprachen, die den Zugriff auf den Speicher einschränken, können diese Arten von Garantien möglich sein und eine aggressivere Optimierung ermöglichen als C ++.

Um die Frage genauer zu formulieren, schlage ich vor, dass der Autor des Buches möglicherweise folgende Einschränkungen im Sinn hatte:

1. Angenommen, der Compiler untersucht das Verhalten einer bestimmten Funktion in Bezug auf die Konstanz einer Variablen. Aus Gründen der Korrektheit müsste ein Compiler (aufgrund des unten erläuterten Aliasing) annehmen, dass die Variable geändert wird, wenn die Funktion eine andere Funktion aufruft. Daher gilt die Annahme Nr. 1 nur für Codefragmente, die keine Funktionsaufrufe ausführen.
2. Angenommen, die Variable wird nicht durch eine asynchrone oder gleichzeitige Aktivität geändert.
3. Angenommen, der Compiler bestimmt nur, ob die Variable geändert werden kann, nicht, ob sie geändert wird. Mit anderen Worten, der Compiler führt nur statische Analysen durch.
4. Angenommen, der Compiler berücksichtigt nur korrekt funktionierenden Code (ohne Berücksichtigung von Array-Über- / Unterläufen, fehlerhaften Zeigern usw.).

Im Zusammenhang mit dem Compiler-Design halte ich die Annahmen 1,3,4 aus Sicht eines Compiler-Writers im Kontext der Code-Gen-Korrektheit und / oder Code-Optimierung für absolut sinnvoll. Annahme 2 ist sinnvoll, wenn das Schlüsselwort volatile nicht vorhanden ist. Und diese Annahmen fokussieren auch die Frage genug, um die Beurteilung einer vorgeschlagenen Antwort viel definitiver zu machen :-)

Angesichts dieser Annahmen ist ein Hauptgrund, warum Konstanz nicht angenommen werden kann, das variable Aliasing. Der Compiler kann nicht wissen, ob eine andere Variable auf die Variable const zeigt. Aliasing kann auf eine andere Funktion in derselben Kompilierungseinheit zurückzuführen sein. In diesem Fall kann der Compiler Funktionen durchsuchen und mithilfe eines Aufrufbaums statisch bestimmen, ob Aliasing auftreten kann. Wenn das Aliasing jedoch auf eine Bibliothek oder einen anderen Fremdcode zurückzuführen ist, kann der Compiler bei der Funktionseingabe nicht feststellen, ob Variablen ein Aliasing aufweisen.

Sie könnten argumentieren, dass eine Variable / ein Argument, die als const markiert ist, nicht durch Aliasing geändert werden sollte, aber für einen Compiler-Writer ist das ziemlich riskant. Es kann für einen menschlichen Programmierer sogar riskant sein, eine Variable const als Teil eines großen Projekts zu deklarieren, bei dem er das Verhalten des gesamten Systems oder des Betriebssystems oder einer Bibliothek nicht kennt, um eine gewonnene Variable wirklich zu kennen. ' t ändern.

Selbst wenn eine Variable deklariert ist const, bedeutet dies nicht, dass schlecht geschriebener Code sie überschreiben kann.

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

Ausgabe:

1
2

Um meine Kommentare zu erweitern, ist der Text dieses Buches unklar, was das Problem verschleiert.

Wie ich kommentierte, versucht dieses Buch zu sagen: "Lassen Sie uns eine unendliche Anzahl von Affen dazu bringen, jede denkbare C ++ - Funktion zu schreiben, die jemals geschrieben werden könnte. Es wird Fälle geben, in denen wir eine Variable auswählen, die (eine bestimmte Funktion, die die Affen geschrieben haben) verwendet, können wir nicht herausfinden, ob die Funktion diese Variable ändern wird. "

Natürlich kann dies für einige (sogar viele) Funktionen in einer bestimmten Anwendung vom Compiler sehr einfach bestimmt werden. Aber nicht für alle (oder unbedingt für die meisten).

Diese Funktion kann einfach so analysiert werden:

static int global;

void foo()
{
}

"foo" ändert "global" eindeutig nicht. Es ändert überhaupt nichts, und ein Compiler kann dies sehr einfach herausfinden.

Diese Funktion kann nicht so analysiert werden:

static int global;

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

Da die Aktionen von "foo" von einem Wert abhängen, der sich zur Laufzeit ändern kann , kann zur Kompilierungszeit offenbar nicht festgestellt werden , ob "global" geändert wird.

Dieses ganze Konzept ist viel einfacher zu verstehen, als es Informatiker vermuten. Wenn die Funktion etwas anderes tun kann, basierend darauf, dass sich die Dinge zur Laufzeit ändern können, können Sie nicht herausfinden, was sie tun wird, bis sie ausgeführt wird, und jedes Mal, wenn sie ausgeführt wird, kann sie etwas anderes tun. Ob es nachweislich unmöglich ist oder nicht, es ist offensichtlich unmöglich.