是否在编译时或运行时解析了用户定义的文字?

Xeo*_*Xeo 10 c++ user-defined-literals c++11

我不知道,因为预定义的文字一样ULL,f等在编译时明显解决.标准(2.14.8 [lex.ext])似乎没有定义这个,但似乎倾向于运行时:

[2.14.8/2]
用户定义的文字被视为对文字运算符或文字运算符模板的调用(13.5.8).要确定具有ud-suffix X的给定用户定义文字L的此调用的形式,使用非限定名称查找规则在L的上下文中查找其文字后缀标识符为X的literal-operator-id( 3.4.1).设S是此查找找到的声明集.S不应该是空的.
(强调我的.)

但是,对我来说,这似乎引入了不必要的运行时开销,因为文字只能附加到编译时可用的值,13.37f或者像"hello"_x(或者_x是用户定义的文字).
然后,我们得到了模板化的用户定义文字,它从未真正在标准AFAICS中定义(即,没有给出示例,请证明我错了).该函数是否在编译时以某种方式神奇地调用,或者它仍然是运行时?

Joh*_*itb 7

是的,你得到一个函数调用.但是由于constexpr文字运算符函数,函数调用可以是编译时常量表达式.

例如,请看这个.作为显示constexprFDIS允许的高级计算形式的另一个例子,您可以使用编译时基数为26的文字

typedef unsigned long long ull;

constexpr ull base26(char const *s, ull ps) {
  return (*s && !(*s >= 'a' && *s <= 'z')) ? throw "bad char!" :
    (!*s ? ps : base26(s + 1, (ps * 26ULL) + (*s - 'a')));
}

constexpr ull operator "" _26(char const *s, std::size_t len) {
  return base26(s, 0);
}
Run Code Online (Sandbox Code Playgroud)

Saying "bcd-"_26将评估throw-expression,从而使返回值变为非常量.反过来,它导致任何使用"bcd-"_26作为常量表达式变得格式不正确,以及任何非常量用法在运行时抛出.允许的形式"bcd"_26评估为相应计算值的常量表达式.

请注意,FDIS没有明确允许从字符串文字读取,但它没有问题,GCC支持这一点(字符左值引用是一个常量表达式,字符的值在编译时是已知的).国际海事组织,如果一个人眯着眼睛,就可以读取FDIS,好像这是允许的.

然后,我们得到了模板化的用户定义文字,它从未真正在标准AFAICS中定义(即,没有给出示例,请证明我错了)

将文字处理为调用文字运算符模板的定义见2.14.8.您可以在13.5.8找到更多关于文字运算符函数/函数模板本身详细信息的示例.

该函数是否在编译时以某种方式神奇地调用,或者它仍然是运行时?

关键字是函数调用替换.见7.1.5.