From Jason Turner

[lex.pptoken]

C++14 → C++17 3.3 KB 41 lines
Current Draft | LaTeX Source
Archived: C++14 | C++17
Markdown: C++14 | C++17
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmpxb9t1mbk/{from.md → to.md} +21 -16
tmp/tmpxb9t1mbk/{from.md → to.md} RENAMED
@@ -1,9 +1,8 @@
1
  ## Preprocessing tokens <a id="lex.pptoken">[[lex.pptoken]]</a>
2
 
3
  ``` bnf
4
- %
5
  preprocessing-token:
6
  header-name
7
  identifier
8
  pp-number
9
  character-literal
@@ -40,39 +39,45 @@ given character:
40
 
41
  - If the next character begins a sequence of characters that could be
42
  the prefix and initial double quote of a raw string literal, such as
43
  `R"`, the next preprocessing token shall be a raw string literal.
44
  Between the initial and final double quote characters of the raw
45
- string, any transformations performed in phases 1 and 2 (trigraphs,
46
- universal-character-names, and line splicing) are reverted; this
47
  reversion shall apply before any *d-char*, *r-char*, or delimiting
48
  parenthesis is identified. The raw string literal is defined as the
49
  shortest sequence of characters that matches the raw-string pattern
50
  ``` bnf
51
  encoding-prefixₒₚₜ 'R' raw-string
52
  ```
53
  - Otherwise, if the next three characters are `<::` and the subsequent
54
- character is neither `:` nor `>`, the `<` is treated as a preprocessor
55
- token by itself and not as the first character of the alternative
56
- token `<:`.
57
  - Otherwise, the next preprocessing token is the longest sequence of
58
  characters that could constitute a preprocessing token, even if that
59
- would cause further lexical analysis to fail.
 
 
 
 
60
 
61
  ``` cpp
62
  #define R "x"
63
  const char* s = R"y"; // ill-formed raw string, not "x" "y"
64
  ```
65
 
66
- The program fragment `1Ex` is parsed as a preprocessing number token
67
- (one that is not a valid floating or integer literal token), even though
68
- a parse as the pair of preprocessing tokens `1` and `Ex` might produce a
69
- valid expression (for example, if `Ex` were a macro defined as `+1`).
70
- Similarly, the program fragment `1E1` is parsed as a preprocessing
71
- number (one that is a valid floating literal token), whether or not `E`
72
- is a macro name.
73
 
74
- The program fragment `x+++++y` is parsed as `x
 
 
 
 
 
 
 
 
75
  ++ ++ + y`, which, if `x` and `y` have integral types, violates a
76
  constraint on increment operators, even though the parse `x ++ + ++ y`
77
- might yield a correct expression.
78
 
 
1
  ## Preprocessing tokens <a id="lex.pptoken">[[lex.pptoken]]</a>
2
 
3
  ``` bnf
 
4
  preprocessing-token:
5
  header-name
6
  identifier
7
  pp-number
8
  character-literal
 
39
 
40
  - If the next character begins a sequence of characters that could be
41
  the prefix and initial double quote of a raw string literal, such as
42
  `R"`, the next preprocessing token shall be a raw string literal.
43
  Between the initial and final double quote characters of the raw
44
+ string, any transformations performed in phases 1 and 2
45
+ (*universal-character-name*s and line splicing) are reverted; this
46
  reversion shall apply before any *d-char*, *r-char*, or delimiting
47
  parenthesis is identified. The raw string literal is defined as the
48
  shortest sequence of characters that matches the raw-string pattern
49
  ``` bnf
50
  encoding-prefixₒₚₜ 'R' raw-string
51
  ```
52
  - Otherwise, if the next three characters are `<::` and the subsequent
53
+ character is neither `:` nor `>`, the `<` is treated as a
54
+ preprocessing token by itself and not as the first character of the
55
+ alternative token `<:`.
56
  - Otherwise, the next preprocessing token is the longest sequence of
57
  characters that could constitute a preprocessing token, even if that
58
+ would cause further lexical analysis to fail, except that a
59
+ *header-name* ([[lex.header]]) is only formed within a `#include`
60
+ directive ([[cpp.include]]).
61
+
62
+ [*Example 1*:
63
 
64
  ``` cpp
65
  #define R "x"
66
  const char* s = R"y"; // ill-formed raw string, not "x" "y"
67
  ```
68
 
69
+ — *end example*]
 
 
 
 
 
 
70
 
71
+ [*Example 2*: The program fragment `0xe+foo` is parsed as a
72
+ preprocessing number token (one that is not a valid floating or integer
73
+ literal token), even though a parse as three preprocessing tokens `0xe`,
74
+ `+`, and `foo` might produce a valid expression (for example, if `foo`
75
+ were a macro defined as `1`). Similarly, the program fragment `1E1` is
76
+ parsed as a preprocessing number (one that is a valid floating literal
77
+ token), whether or not `E` is a macro name. — *end example*]
78
+
79
+ [*Example 3*: The program fragment `x+++++y` is parsed as `x
80
  ++ ++ + y`, which, if `x` and `y` have integral types, violates a
81
  constraint on increment operators, even though the parse `x ++ + ++ y`
82
+ might yield a correct expression. — *end example*]
83