在表达式中使用用户定义的文字有时需要空格 [英] Using user-defined literals in expressions sometimes requires whitespace

问题描述

以下代码在GCC和Clang中均进行编译：

  long double运算符 _a（long double）; 
 auto x = 0e1_a + 0; // OK 
  

但不是这样（替换 _a 与 _e ）：

  long double运算符 __（long双）; 
 auto y = 0e1_e + 0; //错误：找不到数字文字运算符'operator _ e + 0'
  

OTOH，这代码编译：

  auto z = 0e1_e +0; // OK 
  

发生了什么事？

（此问题的灵感来自此GCC错误报告。）

解决方案

再次出现最大的攻击。<​​/ p>

[lex.pptoken] / p3：

如果输入流已解析为预处理令牌，直到给定字符
：

• [这里没有两个相关例外]


• 否则，下一个预处理令牌是可以构成预处理令牌的最长字符序列，即使那样
  将导致进一步的词法分析失败，只是
  header-name （2.8）仅在 #include 指令（16.2）。






问题是 0e1_e +与 0e1_a + 0 不同，0 是有效的预处理数字（[lex.ppnumber]）：

  pp数：
位
。数字
 pp数字数字
 pp数字标识符-非数字
 pp数字'数字
 pp数字'非数字
 pp数字e符号
 pp编号E sign 
 pp编号。 
  

因此， 0e1_e + 0 为解析为单个 pp-number 预处理令牌，然后在以后爆炸，因为它不能转换为有效令牌（出于明显的原因）。

0e1_a + 0 被解析为三个令牌，分别为 0e1_a ， + 和 0 ，一切都很好。

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.)

解决方案

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.

这篇关于在表达式中使用用户定义的文字有时需要空格的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！