tmp/tmpqcfek7vj/{from.md → to.md}
RENAMED
|
@@ -91,18 +91,21 @@ is equivalent to `"\n)\?\?=\"\n"`.
|
|
| 91 |
After translation phase 6, a string literal that does not begin with an
|
| 92 |
*encoding-prefix* is an ordinary string literal, and is initialized with
|
| 93 |
the given characters.
|
| 94 |
|
| 95 |
A string literal that begins with `u8`, such as `u8"asdf"`, is a UTF-8
|
| 96 |
-
string literal
|
| 97 |
-
in UTF-8.
|
| 98 |
|
| 99 |
Ordinary string literals and UTF-8 string literals are also referred to
|
| 100 |
as narrow string literals. A narrow string literal has type “array of
|
| 101 |
*n* `const char`”, where *n* is the size of the string as defined below,
|
| 102 |
and has static storage duration ([[basic.stc]]).
|
| 103 |
|
|
|
|
|
|
|
|
|
|
|
|
|
| 104 |
A string literal that begins with `u`, such as `u"asdf"`, is a
|
| 105 |
`char16_t` string literal. A `char16_t` string literal has type “array
|
| 106 |
of *n* `const char16_t`”, where *n* is the size of the string as defined
|
| 107 |
below; it has static storage duration and is initialized with the given
|
| 108 |
characters. A single *c-char* may produce more than one `char16_t`
|
|
@@ -127,18 +130,18 @@ In translation phase 6 ([[lex.phases]]), adjacent string literals are
|
|
| 127 |
concatenated. If both string literals have the same *encoding-prefix*,
|
| 128 |
the resulting concatenated string literal has that *encoding-prefix*. If
|
| 129 |
one string literal has no *encoding-prefix*, it is treated as a string
|
| 130 |
literal of the same *encoding-prefix* as the other operand. If a UTF-8
|
| 131 |
string literal token is adjacent to a wide string literal token, the
|
| 132 |
-
program is ill-formed. Any other concatenations are
|
| 133 |
-
supported with *implementation-defined* behavior. This
|
| 134 |
-
an interpretation, not a conversion. Because the
|
| 135 |
-
in translation phase 6 (after each character from
|
| 136 |
-
translated into a value from the appropriate
|
| 137 |
-
literal’s initial rawness has no effect on the
|
| 138 |
-
well-formedness of the concatenation. Table
|
| 139 |
-
has some examples of valid concatenations.
|
| 140 |
|
| 141 |
**Table: String literal concatenations** <a id="tab:lex.string.concat">[tab:lex.string.concat]</a>
|
| 142 |
|
| 143 |
| | | | | | |
|
| 144 |
| -------------------------- | ----- | -------------------------- | ----- | -------------------------- | ----- |
|
|
|
|
| 91 |
After translation phase 6, a string literal that does not begin with an
|
| 92 |
*encoding-prefix* is an ordinary string literal, and is initialized with
|
| 93 |
the given characters.
|
| 94 |
|
| 95 |
A string literal that begins with `u8`, such as `u8"asdf"`, is a UTF-8
|
| 96 |
+
string literal.
|
|
|
|
| 97 |
|
| 98 |
Ordinary string literals and UTF-8 string literals are also referred to
|
| 99 |
as narrow string literals. A narrow string literal has type “array of
|
| 100 |
*n* `const char`”, where *n* is the size of the string as defined below,
|
| 101 |
and has static storage duration ([[basic.stc]]).
|
| 102 |
|
| 103 |
+
For a UTF-8 string literal, each successive element of the object
|
| 104 |
+
representation ([[basic.types]]) has the value of the corresponding
|
| 105 |
+
code unit of the UTF-8 encoding of the string.
|
| 106 |
+
|
| 107 |
A string literal that begins with `u`, such as `u"asdf"`, is a
|
| 108 |
`char16_t` string literal. A `char16_t` string literal has type “array
|
| 109 |
of *n* `const char16_t`”, where *n* is the size of the string as defined
|
| 110 |
below; it has static storage duration and is initialized with the given
|
| 111 |
characters. A single *c-char* may produce more than one `char16_t`
|
|
|
|
| 130 |
concatenated. If both string literals have the same *encoding-prefix*,
|
| 131 |
the resulting concatenated string literal has that *encoding-prefix*. If
|
| 132 |
one string literal has no *encoding-prefix*, it is treated as a string
|
| 133 |
literal of the same *encoding-prefix* as the other operand. If a UTF-8
|
| 134 |
string literal token is adjacent to a wide string literal token, the
|
| 135 |
+
program is ill-formed. Any other concatenations are
|
| 136 |
+
conditionally-supported with *implementation-defined* behavior. This
|
| 137 |
+
concatenation is an interpretation, not a conversion. Because the
|
| 138 |
+
interpretation happens in translation phase 6 (after each character from
|
| 139 |
+
a literal has been translated into a value from the appropriate
|
| 140 |
+
character set), a string literal’s initial rawness has no effect on the
|
| 141 |
+
interpretation or well-formedness of the concatenation. Table
|
| 142 |
+
[[tab:lex.string.concat]] has some examples of valid concatenations.
|
| 143 |
|
| 144 |
**Table: String literal concatenations** <a id="tab:lex.string.concat">[tab:lex.string.concat]</a>
|
| 145 |
|
| 146 |
| | | | | | |
|
| 147 |
| -------------------------- | ----- | -------------------------- | ----- | -------------------------- | ----- |
|