C++ source files are processed by the compiler to produce C++ programs.

[edit]Translation process

The text of a C++ program is kept in units calledsource files.

C++ source files undergotranslation to become atranslation unit, consisting of the following steps:

1. Maps each source file to a character sequence.
2. Converts each character sequence to a preprocessing token sequence, separated by whitespace.
3. Converts each preprocessing token to a token, forming a token sequence.
4. Converts each token sequence to a translation unit.

A C++ program can be formed from translated translation units. Translated translation units and instantiated units (instantiated units are described in phase 8 below) can be saved individually or saved into a library. Multiple translation units communicate with each other through (for example) symbols with external linkage or data files. Translation units can be separately translated and then later linked to produce an executable program.

The process above can be organized into 9translation phases.

[edit]Preprocessing tokens

Apreprocessing token is the minimal lexical element of the language in translation phases 3 through 6.

The categories of preprocessing token are:

• header names (such as<iostream> or"myfile.h")

• identifiers
• preprocessing numbers (see below)
• character literals, includinguser-defined character literals(since C++11)
• string literals, includinguser-defined string literals(since C++11)
• operators and punctuators, includingalternative tokens
• individual non-whitespace characters that do not fit in any other category

The program is ill-formed if the character matching this category is

• apostrophe (', U+0027),
• quotation mark (", U+0022), or
• a character not in thebasic character set.

[edit]Preprocessing numbers

The set of preprocessing tokens of preprocessing number is a superset of the union of the sets of tokens ofinteger literals andfloating-point literals:

Eachpp-continue is one of the following:

A preprocessing number does not have a type or a value; it acquires both after a successful conversion an integer/floating-point literal token.

[edit]Whitespace

Whitespace consists ofcomments, whitespace characters, or both.

The following characters are whitespace characters:

• character tabulation (U+0009)
• line feed / new-line character (U+000A)
• line tabulation (U+000B)
• form feed (U+000C)
• space (U+0020)

Whitespace is usually used to separate preprocessing tokens, with the following exceptions:

• It is not a separator in header name, character literal and string literal.
• Preprocessing tokens separated by whitespace containing new-line characters cannot formpreprocessing directives.

#include "my header"        // OK, using a header name containing whitespace #include/*hello*/<iostream> // OK, using a comment as whitespace #include<iostream>// Error: #include cannot span across multiple lines "str ing"// OK, a single preprocessing token (string literal)' '// OK, a single preprocessing token (character literal)

[edit]Maximal munch

The maximal munch is the rule used in phase 3 when decomposing the source file into preprocessing tokens.

If the input has been parsed into preprocessing tokens up to a given character (otherwise, the next preprocessing token will not be parsed, which makes the parsing order unique), the next preprocessing token is generally taken to be the longest sequence of characters that could constitute a preprocessing token, even if that would cause subsequent analysis to fail. This is commonly known asmaximal munch.

int foo=1;int bar=0xE+foo;// Error: invalid preprocessing number 0xE+fooint baz=0xE+ foo;// OK

In other words, the maximal munch rule is in favor ofmulti-character operators and punctuators:

int foo=1;int bar=2; int num1= foo+++++bar;// Error: treated as “foo++ ++ +baz”, not “foo++ + ++baz”int num2=-----foo;// Error: treated as “-- -- -foo”, not “- -- --foo”

The maximal munch rule has the following exceptions:

• Header name preprocessing tokens are only formed in the following cases:

• after theinclude preprocessing token in an#include directive

std::vector<int> x;// OK, “int” is not a header name

• If the next three characters are<:: and the subsequent character is neither: nor>, the< is treated as a preprocessing token by itself instead of the first character of thealternative token<:.

struct Foo{staticconstint v=1;};std::vector<::Foo> x;// OK, <: not taken as the alternative token for [externint y<::>;// OK, same as “extern int y[];”int z<:::Foo::value:>;// OK, same as “int z[::Foo::value];”

template<int i>class X{/* ... */};template<class T>class Y{/* ... */}; Y<X<1>> x3;// OK, declares a variable “x3” of type “Y<X<1> >”Y<X<6>>1>> x4;// Syntax errorY<X<(6>>1)>> x5;// OK

#define R "x"constchar* s= R"y";// ill-formed raw string literal, not "x" "y"constchar* s2= R"(a)""b)";// a raw string literal followed by a normal string literal

[edit]Tokens

Atoken is the minimal lexical element of the language in translation phase 7.

The categories of token are:

• identifiers
• keywords
• literals
• operators and punctuators (except preprocessing operators)

[edit]Translation phases

Translation is performedas if in the order from phase 1 to phase 9. Implementations behave as if these separate phases occur, although in practice different phases can be folded together.

[edit]Phase 1: Mapping source characters

[edit]Phase 2: Splicing lines

[edit]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

[edit]Phase 4: Preprocessing

[edit]Phase 5: Determining common string literal encodings

[edit]Phase 6: Concatenating string literals

Adjacentstring literals are concatenated.

[edit]Phase 7: Compiling

Compilation takes place: each preprocessing token is converted to atoken. The tokens are syntactically and semantically analyzed and translated as atranslation unit.

[edit]Phase 8: Instantiating templates

Each translation unit is examined to produce a list of required template instantiations, including the ones requested byexplicit instantiations. The definitions of the templates are located, and the required instantiations are performed to produceinstantiation units.

[edit]Phase 9: Linking

Translation units, instantiation units, and library components needed to satisfy external references are collected into a program image which contains information needed for execution in its execution environment.

[edit]Notes

Source files, translation units and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation. The description is conceptual only, and does not specify any particular implementation.

Some compilers do not implement instantiation units (also known astemplate repositories ortemplate registries) and simply compile each template instantiation at phase 7, storing the code in the object file where it is implicitly or explicitly requested, and then the linker collapses these compiled instantiations into one at phase 9.

[edit]Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

[edit]References

[edit]See also

• In other languages

• Español
• 日本語
• Polski
• Русский
• 中文