Using user-defined literals in expressions sometimes requires whitespace

懵懂的女人 提交于 2020-01-21 11:07:26

问题


The following code compiles in both GCC and Clang:

long double operator""_a(long double);     
auto x = 0e1_a+0; // OK 

But not this (replacing _a with _e):

long double operator""_e(long double);
auto y = 0e1_e+0; // Error: unable to find numeric literal operator 'operator""_e+0'

OTOH, this code compiles:

auto z = 0e1_e +0; // OK

What's going on?

(This question is inspired by this GCC bug report.)


回答1:


Maximal munch strikes again.

[lex.pptoken]/p3:

If the input stream has been parsed into preprocessing tokens up to a given character:

  • [two exceptions not relevant here]
  • Otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail, except that a header-name (2.8) is only formed within a #include directive (16.2).

The problem is that 0e1_e+0, unlike 0e1_a+0, is a valid preprocessing number ([lex.ppnumber]):

pp-number:
    digit
    . digit
    pp-number digit
    pp-number identifier-nondigit
    pp-number ’ digit
    pp-number ’ nondigit
    pp-number e sign
    pp-number E sign
    pp-number .

As a result, 0e1_e+0 is parsed as a single pp-number preprocessing token, and then explodes later because it cannot be converted to a valid token (for obvious reasons).

0e1_a+0, on the other hand, is parsed as three tokens, 0e1_a, +, and 0, and all is well.



来源:https://stackoverflow.com/questions/33670238/using-user-defined-literals-in-expressions-sometimes-requires-whitespace

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!