使用用户定义文字的成员时编译错误 [英] Compile error when using a member of a user-defined literal

问题描述

编译此代码时（没有任何标题）

When compiling this code (without any header)

template <typename T>
struct Temperature {
    T temp;

    explicit Temperature(T t)
        : temp(t)
    {}
};

Temperature<long double> operator "" _f (long double t)
{
    return Temperature<long double>((t - 32) / 1.8);
}

int main()
{
    auto t = 100.0_f;
    t.temp;

    100.0_f.temp; // ERROR AT THIS LINE
    return 0;
}

编译器（Ubuntu 14.04上的g ++ 4.8和clang ++ 3.4）

The compilers (both g++ 4.8 and clang++ 3.4 on Ubuntu 14.04) will complain that

error: unable to find numeric literal operator ‘operator"" _f.temp’
     100.0_f.temp;
     ^

似乎 _f.temp 被视为后缀。为什么编译器这样解析，而不是停在点？

It seems that the _f.temp is considered as a suffix there. Why do the compilers parse it like that, instead of stopping at the dot?

推荐答案

预处理数字是奇数野兽，主要用于使预处理器更容易书写。

Preprocessing numbers are odd beasts, specified mostly to make the preprocessor easier to write.

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 p sign
    pp-number P sign
    pp-number .

12 -number 令牌，因此是 0xe + foo （参见[lex.pptoken] / 4中的示例），因此。 12.CA'TS_RULE..56.me + owp-urr 。如果后两者使它过去翻译阶段6，则程序是不成形的，因为它不能在阶段7转换为有效的令牌。然而，在那之前，它是有效的，所以最大munch说我们解析 0xe + foo 或 100.0_f.temp 作为单个预处理令牌。

12 is a valid pp-number token, so is 0xe+foo (see the example in [lex.pptoken]/4), and so is .12.CA'TS_RULE..56.me+owp-urr. If the latter two make it past translation phase 6, then the program is ill-formed because it cannot be converted to a valid token in phase 7. Until then, however, it is valid, so maximal munch says we parse 0xe+foo or 100.0_f.temp as a single preprocessing token.

这篇关于使用用户定义文字的成员时编译错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！