Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #71426
| From | Manfred <noname@add.invalid> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: C++ preprocessor and multi-line string literals |
| Date | 2020-01-16 22:49 +0100 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <qvqloc$1ami$1@gioia.aioe.org> (permalink) |
| References | <qvpvvf$h2p$1@dont-email.me> <92fc27c6-1146-4820-8bb3-54075c5b9fa4@googlegroups.com> |
On 1/16/2020 6:46 PM, Öö Tiib wrote:
> On Thursday, 16 January 2020 17:37:31 UTC+2, Paavo Helde wrote:
>> In C++ there is a preprocessor step which logically comes first and
>> prepares the preprocessed source consisting of remaining tokens.
>> However, preprocessor is line-based, so it ought to conflict with the
>> multi-line string literals:
>>
>> #include <iostream>
>>
>> #if 1
>>
>> int main() {
>> const char* test = R"__(
>>
>> #else
>>
>> )__";
>> std::cout << test;
>> }
>>
>> #endif
>>
>> Obviously C++ compilers supporting C++11 are able to cope with that and
>> handle the '#else' line as part of the string literal. My question is
>> more about how they were able to standardize this behavior? Is there
>> still a logically separate preprocessor step or not?
>>
>> By googling I also find some EBNF formal syntax descriptions for C++,
>> but these are different for the preprocessor and for the actual C++
>> language. With presence of multi-line string literals, is it even
>> possible to provide a self-consistent EBNF formal syntax for the C++
>> preprocessor?
>
> [lex.phases]1.1.
> | Physical source file characters are mapped, in an implementation-defined
> | manner, to the basic source character set (introducing new-line
> | characters for end-of-line indicators) if necessary. The set of
> | physical source file characters accepted is implementation-defined. Any
> | source file character not in the basic source character set (5.3) is
> | replaced by the universal-character-name that designates that
> | character. An implementation may use any internal encoding, so long
> | as an actual extended character encountered in the source file, and
> | the same extended character expressed in the source file as a
> | universal-charactername (e.g., using the \uXXXX notation), are
> | handled equivalently except where this replacement is reverted (5.4)
> | in a *raw* *string* *literal*.
>
> So the raw string literal is already a token of very first translation
> step. Preprocessing takes place in step 4. By that time it has been
> string literal for 3 steps already.
>
(Using n4820.pdf)
I think the reference in here of a string literal is a forward reference
(to section 5.4 [lex.pptoken]) and it only applies to handling of
universal-character-names, it does not define string literals yet.
However, step 3 of [lex.phases] says: "The source file is decomposed
into preprocessing tokens (5.4)".
Preprocessing tokens are defined in [lex.pptoken] (section 5.4 in
n4820), and the list includes "string-literal" (specifically, it is
defined at p3.1).
The following step 4 then executes preprocessing directives.
So, yes string literals are processed before preprocessing directives,
but one step earlier, not three.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C++ preprocessor and multi-line string literals Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-16 17:37 +0200
Re: C++ preprocessor and multi-line string literals Öö Tiib <ootiib@hot.ee> - 2020-01-16 09:46 -0800
Re: C++ preprocessor and multi-line string literals Manfred <noname@add.invalid> - 2020-01-16 22:49 +0100
Re: C++ preprocessor and multi-line string literals Öö Tiib <ootiib@hot.ee> - 2020-01-16 14:43 -0800
Re: C++ preprocessor and multi-line string literals Manfred <invalid@add.invalid> - 2020-01-17 01:24 +0100
Re: C++ preprocessor and multi-line string literals Öö Tiib <ootiib@hot.ee> - 2020-01-16 16:38 -0800
Re: C++ preprocessor and multi-line string literals Manfred <invalid@add.invalid> - 2020-01-17 03:27 +0100
Re: C++ preprocessor and multi-line string literals legalize+jeeves@mail.xmission.com (Richard) - 2020-01-16 20:07 +0000
Re: C++ preprocessor and multi-line string literals Juha Nieminen <nospam@thanks.invalid> - 2020-01-20 13:53 +0000
Re: C++ preprocessor and multi-line string literals Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-20 18:31 +0200
Re: C++ preprocessor and multi-line string literals Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-20 18:19 +0100
Re: C++ preprocessor and multi-line string literals Juha Nieminen <nospam@thanks.invalid> - 2020-01-21 08:24 +0000
Re: C++ preprocessor and multi-line string literals boltar@nowhere.org - 2020-01-21 16:43 +0000
Re: C++ preprocessor and multi-line string literals Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-21 19:25 +0200
Re: C++ preprocessor and multi-line string literals boltar@nowhere.org - 2020-01-22 09:58 +0000
Re: C++ preprocessor and multi-line string literals guinness.tony@gmail.com - 2020-01-22 02:11 -0800
Re: C++ preprocessor and multi-line string literals boltar@nowhere.org - 2020-01-22 10:24 +0000
Re: C++ preprocessor and multi-line string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-23 22:25 -0500
Re: C++ preprocessor and multi-line string literals Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-22 13:28 +0200
Re: C++ preprocessor and multi-line string literals boltar@nowhere.org - 2020-01-22 12:07 +0000
Re: C++ preprocessor and multi-line string literals Öö Tiib <ootiib@hot.ee> - 2020-01-22 05:33 -0800
Re: C++ preprocessor and multi-line string literals boltar@nowhere.org - 2020-01-22 16:03 +0000
Re: C++ preprocessor and multi-line string literals Öö Tiib <ootiib@hot.ee> - 2020-01-22 10:50 -0800
Re: C++ preprocessor and multi-line string literals boltar@nowhere.org - 2020-01-23 09:22 +0000
Re: C++ preprocessor and multi-line string literals Manfred <noname@add.invalid> - 2020-01-22 18:59 +0100
Re: C++ preprocessor and multi-line string literals Juha Nieminen <nospam@thanks.invalid> - 2020-01-22 12:03 +0000
csiph-web