1

At [over.literal] I read, in the list of examples, that

double operator""_Bq(long double);

is valid, whereas

double operator"" _Bq(long double);

is ill-formed, which is apparently a consequence of the space right after "".

Now, from the linked page, I can easily get to [usrlit.suffix] with one click and I read that

Literal suffix identifiers that do not start with an underscore are reserved for future standardization.

Good, but where do I read why operator"" _Bq is invalid?

I've also read the description of user-defined-string-literal on cppreference, but to be honest I've found it a bit confusing.

Can anybody break that down with examples?

Improve this question
12
  • 7
    The comment next to the second example says why it's not allowed - _Bq is a reserved name per eel.is/c++draft/lex.name#3.1 (_ followed by uppercase letter). Note that the example _km is fine. Commented Feb 6, 2023 at 9:58
  • 1
    It says "ill-formed NDR", not just "ill-formed". Commented Feb 6, 2023 at 9:59
  • 7
    Adding a space opens it up for macro expansion. operator""_Bq is one pptoken, whereas operator"" _Bq is two pptokens, and the second one can be expanded if an implementation defines a macro with (reserved) name that is _Bq. Commented Feb 6, 2023 at 10:14
  • 1
    Anyway, if one follows the grammar productions and tries not to be intentionally obtuse, there is a plug in that hole @Enlico. The space breaks it up for preprocessing. It's not about the standard using operator"" _Bq, it's about _Bq being it's own "thing" lexically. Commented Feb 6, 2023 at 10:23
  • 3
    Instead of operator"" _Bq try operator"" _DEBUG and see what happens. Commented Feb 6, 2023 at 10:42

1 Answer 1

Reset to default
7

"" _Bq is a string-literal followed by an identifier, whereas ""_Bq is a user-defined-string-literal which is a single, distinct preprocessing token ([lex.pptoken]).

As a consequence, the former is affected by macro expansion, but the latter is not:

#define _x int operator "" _x(char); // becomes `int operator "" (char);` which is invalid int operator ""_x(char); // ok

That aside, both forms are allowed as part of a literal-operator-id and have the same meaning. However, since forming the first construct involves the use of a reserved identifier, it is ill-formed with no diagnostic required per [lex.name]/3 (motivation for this being that _Bq could be in use by the implementation as a macro).

That's the intent, anyway. The current normative wording does not actually make that difference clear enough: user-defined-string-literal ultimately contains an identifier, and [lex.name]/3 has no indication that it only applies to identifiers that are themselves preprocessing tokens. This is the subject of CWG2521.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.