Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #71438

Re: C++ preprocessor and multi-line string literals

Show all headers | View raw

On 1/17/20 1:38 AM, Öö Tiib wrote:
> On Friday, 17 January 2020 02:25:04 UTC+2, Manfred  wrote:
>> On 1/16/20 11:43 PM, Öö Tiib wrote:
>>> On Thursday, 16 January 2020 23:49:14 UTC+2, Manfred  wrote:
>>>> 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.
>>>
>>> Are you suggesting what are the raw string literals should be
>>> re-decided in later steps?
>>>
>>>
>>
>> No, "what are the raw string literals" is "decided" in step 3, and not
>> in step 1.
>> I suggest you re-read step 1, more carefully.
> 
> Maybe I am confused indeed. Can we compose raw string literals
> using \u0052 <- 'R' in step 1 for later steps?
> 

Step 1 is not about composing raw string literals.
Do you mean \u0052"__(Hello World!)__" ?

This doesn't seem to work, in fact step 1 talks about conversion of 
"extended characters", and R is not an extended character.

[lex.charset] says that "The universal-character-name construct provides 
a way to name other characters" than the basic ones.

This might be the reason why gcc complains about universal character not 
allowed in the above.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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