c++ 运算符””_Bq有什么问题？

hgqdbh6s 于 2023-02-10 发布在其他

关注(0)|答案(1)|浏览(114)

在over.literal(http://eel.is/c++draft/over.literal)中，我在示例列表中看到

double operator""_Bq(long double);

是有效的，而

double operator"" _Bq(long double);

是病态的，这显然是""后面的空格造成的。
现在，从链接的页面，我可以很容易地通过一次点击进入usrlit.suffix(http://eel.is/c++draft/usrlit.suffix)，我读到了
不以下划线开头的文本后缀标识符保留用于将来的标准化。
很好，但是我在哪里读到为什么operator"" _Bq是无效的呢？
我也读过user-defined-string-literal对cppreference的描述，但老实说，我觉得有点混乱。
有人能举例说明吗？

c++

来源：https://stackoverflow.com/questions/75359738/what-is-wrong-with-operator-bq

1条答案

按热度按时间

7lrncoxx1#

"" _Bq是后跟 * 标识符 * 的 * 字符串文本 *，而""_Bq是 * 用户定义的字符串文本 *，它是单个不同的预处理标记（[lex.pptoken]）。
因此，前者受宏观扩张的影响，而后者则不受影响：

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

除此之外，这两种形式都允许作为 literal-operator-id 的一部分，并且具有相同的含义。但是，由于形成第一个构造涉及使用保留的 identifier，因此它是病态的，不需要根据[lex.name]/3进行诊断（这样做的动机是_Bq可能被实现用作宏）。
无论如何，这就是“意图”，目前的规范性措辞实际上并没有足够清楚地说明这一区别：user-defined-string-literal 最终包含一个 identifier，并且[lex.name]/3没有指示它只适用于本身是预处理标记的标识符。

赞(0）回复(0）举报 2023-02-10

我来回答

c++ 运算符””_Bq有什么问题？

1条答案

相关问题

热门标签

最新问答