用户定义的数字文字可以紧跟一个点吗? [英] Can user defined numeric literals be immediately followed by a dot?

问题描述

自C ++ 11起，就可以创建用户定义的文字.如预期的那样，可以从此类文字中返回复杂的结构.但是，当尝试使用123_foo.bar():

这样的运算符时

struct foo {
    int n;
    int bar() const { return n; }
};

constexpr foo operator ""_foo(unsigned long long test)
{
    return foo{ static_cast<int>(test) };
}

int main() {
    return 123_foo.bar();
}

GCC和Clang拒绝了，说他们找不到operator""_foo.bar. MSVC接受它.如果我改写123_foo .bar()，则所有三个编译器都接受

谁在这里? 123_foo.bar()曾经有效吗?

---

一些额外的信息:

• 三个人都接受字符串文字
• std::chrono文字也存在问题

---

我倾向于认为这是GCC和Clang错误，因为.不是有效标识符的一部分.

解决方案

TLDR Clang和GCC是正确的，您不能在用户定义的整数/浮点文字后立即编写.，这是MSVC错误. /p>

程序编译后，会经历翻译的9个阶段顺序.这里要注意的关键是在考虑其语义之前将源代码分解(分离)成令牌.

在此阶段，最大mu口生效，就是说，令牌被视为语法上有效的最长字符序列.例如，即使x+++++y在语义上无效，也将其分类为x ++ ++ + y而不是x + ++ ++ y.

那么问题是123_foo.bar的最长语法有效序列是什么.遵循生产规则的预处理编号，确切的顺序是

pp-number→pp-number标识符-非数字→...→pp-number标识符-非数字³→
pp-numbernondigit³→pp-number.非数字³→...→pp数非数字⁴.非数字³→
pp-number digitnondigit⁴.非数字³→...→pp位数²非数字⁴.非数字³→
digit³nondigit⁴.非数字³

如错误消息所示，解析为123_foo.bar

Since C++11, it has been possible to create User Defined Literals. As expected, it's possible to return complex structs from such literals. However, when trying to use such operators as 123_foo.bar():

struct foo {
    int n;
    int bar() const { return n; }
};

constexpr foo operator ""_foo(unsigned long long test)
{
    return foo{ static_cast<int>(test) };
}

int main() {
    return 123_foo.bar();
}

GCC and Clang reject it, saying they can't find an operator""_foo.bar. MSVC accepts it. If I instead write 123_foo .bar(), all three compilers accept it

Who is right here? Is 123_foo.bar() ever valid?

---

Some extra information:

• All three accept it for string literals
• The problem exists for std::chrono literals as well

---

I'm inclined to believe that this is a GCC and Clang bug, as . is not part of a valid identifier.

解决方案

TLDR Clang and GCC are correct, you can't write a . right after a user defined integer/floating literal, this is a MSVC bug.

When a program gets compiled, it goes through 9 phases of translations in order. The key thing to note here is lexing (seperating) the source code into tokens is done before taking into consideration its semantic meaning.

In this phase, maximal munch is in effect, that is, tokens are taken as the longest sequence of characters that is syntactically valid. For example x+++++y is lexed as x ++ ++ + y instead of x + ++ ++ y even if the former isn't semantically valid.

The question is then what is the longest syntactically valid sequence for 123_foo.bar. Following the production rules for a preprocessing number, the exact sequence is

pp-number → pp-number identifier-nondigit → ... → pp-number identifier-nondigit³ →
pp-number nondigit³ → pp-number . nondigit³ → ... → pp-number nondigit⁴ . nondigit³ →
pp-number digit nondigit⁴ . nondigit³ → ... → pp-number digit² nondigit⁴ . nondigit³ →
digit³ nondigit⁴ . nondigit³

Which resolves to 123_foo.bar as seen in the error message

这篇关于用户定义的数字文字可以紧跟一个点吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！