| 1. | Physical source file characters are mapped, in an
implementation-defined manner,
to the translation character set ([lex.charset])
(introducing new-line characters for end-of-line indicators). The set of physical source file characters accepted is implementation-defined. |
| 2. | Each sequence of a backslash character (\)
immediately followed by
zero or more whitespace characters other than new-line followed by
a new-line character is deleted, splicing
physical source lines to form logical source lines. Only the last
backslash on any physical source line shall be eligible for being part
of such a splice. Except for splices reverted in a raw string literal, if a splice results in
a character sequence that matches the
syntax of a universal-character-name, the behavior is
undefined. A source file that is not empty and that does not end in a new-line
character, or that ends in a splice,
shall be processed as if an additional new-line character were appended
to the file. |
| 3. | The source file is decomposed into preprocessing
tokens ([lex.pptoken]) and sequences of whitespace characters
(including comments).
Each comment is replaced by one space character. New-line characters are
retained. Whether each nonempty sequence of whitespace characters other
than new-line is retained or replaced by one space character is
unspecified. As characters from the source file are consumed
to form the next preprocessing token
(i.e., not being consumed as part of a comment or other forms of whitespace),
except when matching a
c-char-sequence,
s-char-sequence,
r-char-sequence,
h-char-sequence, or
q-char-sequence,
universal-character-names are recognized and
replaced by the designated element of the translation character set. The process of dividing a source file's
characters into preprocessing tokens is context-dependent. |
| 4. | Preprocessing directives are executed, macro invocations are
expanded, and _Pragma unary operator expressions are executed. A #include preprocessing directive causes the named header or
source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted. |
| 5. | For a sequence of two or more adjacent string-literal tokens,
a common encoding-prefix is determined
as specified in [lex.string]. |
| 6. | |
| 7. | Whitespace characters separating tokens are no longer
significant. Each preprocessing token is converted into a
token ([lex.token]). The resulting tokens are syntactically and
semantically analyzed and translated as a translation unit. [Note 1: The process of analyzing and translating the tokens can occasionally
result in one token being replaced by a sequence of other
tokens ([temp.names]). — end note]
It is
implementation-defined
whether the sources for
module units and header units
on which the current translation unit has an interface
dependency ([module.unit], [module.import])
are required to be available. [Note 2: 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. — end note] |
| 8. | Translated translation units and instantiation units are combined
as follows:
Each translated translation unit is examined to
produce a list of required instantiations. [Note 4: This can include
instantiations which have been explicitly
requested ([temp.explicit]). — end note]
The definitions of the
required templates are located. It is implementation-defined whether the
source of the translation units containing these definitions is required
to be available.
All the required instantiations
are performed to produce
instantiation units.
The
program is ill-formed if any instantiation fails. |
| 9. |