Phases of translation

C++-Quelldateien werden vom Compiler verarbeitet, um C++-Programme zu erstellen.

Übersetzungsprozess

Der Text eines C++-Programms wird in Einheiten namens source files gespeichert.

C++-Quelldateien durchlaufen Translation , um eine Translation Unit zu werden, die aus den folgenden Schritten besteht:

1. Ordnet jede Quelldatei einer Zeichenfolge zu.
2. Konvertiert jede Zeichenfolge in eine Präprozessor-Token-Sequenz, getrennt durch Leerzeichen.
3. Konvertiert jedes Präprozessor-Token in ein Token und bildet eine Token-Sequenz.
4. Konvertiert jede Token-Sequenz in eine Übersetzungseinheit.

Ein C++-Programm kann aus übersetzten Übersetzungseinheiten gebildet werden. Übersetzte Übersetzungseinheiten und instanziierte Einheiten (instanziierte Einheiten werden in Phase 8 unten beschrieben) können individuell gespeichert oder in einer Bibliothek gespeichert werden. Mehrere Übersetzungseinheiten kommunizieren miteinander durch (beispielsweise) Symbole mit externer Bindung oder Datendateien. Übersetzungseinheiten können separat übersetzt und später gebunden werden, um ein ausführbares Programm zu erzeugen.

Der oben beschriebene Prozess kann in 9 Übersetzungsphasen unterteilt werden.

Präprozessor-Tokens

Ein Präprozessor-Token ist das minimale lexikalische Element der Sprache in den Übersetzungsphasen 3 bis 6.

Die Kategorien von Präprozessor-Token sind:

• Header-Namen (wie < iostream > oder "myfile.h" )

• Identifikatoren
• Präprozessorzahlen (siehe unten)
• Zeichenliterale , einschließlich benutzerdefinierter Zeichenliterale (seit C++11)
• Zeichenkettenliterale , einschließlich benutzerdefinierter Zeichenkettenliterale (seit C++11)
• Operatoren und Interpunktoren , einschließlich alternativer Tokens
• einzelne Nicht-Leerzeichen-Zeichen, die in keine andere Kategorie passen

Das Programm ist fehlerhaft, wenn das Zeichen, das dieser Kategorie entspricht,

• Apostroph ( ' , U+0027),
• Anführungszeichen ( " , U+0022), oder
• ein Zeichen außerhalb des Basiszeichensatzes ist.

Präprozessorzahlen

Die Menge der Präprozessor-Tokens einer Präprozessornummer ist eine Obermenge der Vereinigung der Mengen der Tokens von Integer-Literalen und Gleitkomma-Literalen :

Jeder pp-continue ist einer der Folgenden:

Eine Präprozessornummer hat keinen Typ oder Wert; sie erhält beides nach einer erfolgreichen Umwandlung in ein Integer-/Fließkomma-Literal-Token.

Whitespace

Whitespace besteht aus Kommentaren , Whitespace-Zeichen oder beidem.

Die folgenden Zeichen sind Leerzeichen:

• Zeichentabulator (U+0009)
• Zeilenvorschub / Zeilenumbruchzeichen (U+000A)
• Zeilentabulator (U+000B)
• Seitenvorschub (U+000C)
• Leerzeichen (U+0020)

Whitespace wird normalerweise verwendet, um Präprozessor-Tokens zu trennen, mit den folgenden Ausnahmen:

• Es ist kein Trennzeichen in Header-Namen, Zeichenliteralen und Zeichenkettenliteralen.
• Präprozessortoken, die durch Leerzeichen mit Zeilenumbruchzeichen getrennt sind, können keine Präprozessordirektiven bilden.

#include "my header"        // OK, Verwendung eines Header-Namens mit Leerzeichen
#include/*hello*/<iostream> // OK, Verwendung eines Kommentars als Leerzeichen
#include
<iostream> // Fehler: #include kann sich nicht über mehrere Zeilen erstrecken
"str ing"  // OK, ein einzelner Präprozessor-Token (String-Literal)
' '        // OK, ein einzelner Präprozessor-Token (Zeichen-Literal)

Maximal Munch

Die maximale Munch ist die Regel, die in Phase 3 bei der Zerlegung der Quelldatei in Präprozessor-Token verwendet wird.

Wenn die Eingabe bis zu einem bestimmten Zeichen in Präprozessor-Token geparst wurde (ansonsten wird das nächste Präprozessor-Token nicht geparst, was die Parsing-Reihenfolge eindeutig macht), wird das nächste Präprozessor-Token generell als die längste Zeichensequenz genommen, die ein Präprozessor-Token bilden könnte, selbst wenn dies dazu führt, dass die nachfolgende Analyse fehlschlägt. Dies ist allgemein bekannt als maximal munch .

int foo = 1;
int bar = 0xE+foo;   // Fehler: ungültige Präprozessor-Zahl 0xE+foo
int baz = 0xE + foo; // OK

Mit anderen Worten, die Maximal-Munch-Regel begünstigt mehrzeilige Operatoren und Interpunktionszeichen :

int foo = 1;
int bar = 2;
int num1 = foo+++++bar; // Fehler: wird als "foo++ ++ +baz" interpretiert, nicht als "foo++ + ++baz"
int num2 = -----foo;    // Fehler: wird als "-- -- -foo" interpretiert, nicht als "- -- --foo"

Die Maximal-Munch-Regel hat die folgenden Ausnahmen:

• Header-Name-Präprozessor-Token werden nur in den folgenden Fällen gebildet:

• nach dem include Präprozessor-Token in einer #include Direktive

std::vector<int> x; // OK, „int“ ist kein Header-Name

• Wenn die nächsten drei Zeichen < :: sind und das folgende Zeichen weder : noch > ist, wird das < als eigenständiges Präprozessor-Token behandelt anstatt als erstes Zeichen des alternativen Tokens < : .

struct Foo { static const int v = 1; };
std::vector<::Foo> x;  // OK, <: nicht als Alternativtoken für [ interpretiert
extern int y<::>;      // OK, gleichbedeutend mit "extern int y[];"
int z<:::Foo::value:>; // OK, gleichbedeutend mit "int z[::Foo::value];"

template<int i> class X { /* ... */ };
template<class T> class Y { /* ... */ };
Y<X<1>> x3;      // OK, deklariert eine Variable „x3“ vom Typ „Y<X<1> >“
Y<X<6>>1>> x4;   // Syntaxfehler
Y<X<(6>>1)>> x5; // OK

#define R "x"
const char* s = R"y";         // ungültiges Raw-String-Literal, nicht "x" "y"
const char* s2 = R"(a)" "b)"; // ein Raw-String-Literal gefolgt von einem normalen String-Literal

Token

Ein Token ist das minimale lexikalische Element der Sprache in Übersetzungsphase 7.

Die Kategorien von Token sind:

• Bezeichner
• Schlüsselwörter
• Literale
• Operatoren und Interpunktoren (außer Präprozessor-Operatoren)

Übersetzungsphasen

Die Übersetzung erfolgt as if in der Reihenfolge von Phase 1 bis Phase 9. Implementierungen verhalten sich so, als ob diese separaten Phasen auftreten, obwohl in der Praxis verschiedene Phasen zusammengefasst werden können.

Phase 1: Zuordnung von Quellzeichen

Phase 2: Zeilenverknüpfung

Phase 3: Lexing

// The following #include directive can de decomposed into 5 preprocessing tokens:
//     punctuators (#, < and >)
//          │
// ┌────────┼────────┐
// │        │        │
   #include <iostream>
//     │        │
//     │        └── header name (iostream)
//     │
//     └─────────── identifier (include)

// Error: partial string literal
"abc

// Error: partial comment
/* comment

Phase 4: Vorverarbeitung

Phase 5: Bestimmung gängiger String-Literal-Kodierungen

Phase 6: Verkettung von String-Literalen

Benachbarte String-Literale werden verkettet.

Phase 7: Kompilierung

Die Kompilierung findet statt: Jeder Präprozessor-Token wird in einen Token umgewandelt. Die Tokens werden syntaktisch und semantisch analysiert und als eine Translation Unit übersetzt.

Phase 8: Instanziierung von Templates

Jede Übersetzungseinheit wird geprüft, um eine Liste der benötigten Template-Instanziierungen zu erstellen, einschließlich derjenigen, die durch explizite Instanziierungen angefordert werden. Die Definitionen der Templates werden lokalisiert, und die erforderlichen Instanziierungen werden durchgeführt, um Instanziierungseinheiten zu erzeugen.

Phase 9: Linking

Übersetzungseinheiten, Instanziierungseinheiten und Bibliothekskomponenten, die zur Erfüllung externer Referenzen benötigt werden, werden in ein Programmabbild gesammelt, das die für die Ausführung in seiner Ausführungsumgebung benötigten Informationen enthält.

Hinweise

Quelldateien, Übersetzungseinheiten und übersetzte Übersetzungseinheiten müssen nicht unbedingt als Dateien gespeichert werden, noch muss es eine Eins-zu-eins-Entsprechung zwischen diesen Entitäten und einer externen Darstellung geben. Die Beschreibung ist nur konzeptionell und spezifiziert keine bestimmte Implementierung.

Einige Compiler implementieren keine Instanziierungseinheiten (auch bekannt als template repositories oder template registries ) und kompilieren einfach jede Template-Instanziierung in Phase 7, speichern den Code in der Objektdatei, wo er implizit oder explizit angefordert wird, und anschließend reduziert der Linker diese kompilierten Instanziierungen in Phase 9 auf eine.

Fehlerberichte

Die folgenden verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.

Referenzen

Siehe auch