为什么非下划线名称保留给 UDL 的实现，而不是相反

Why are non underscore names reserved to the implementation for UDL and not the other way around?

本文关键字：实现 UDL 下划线 保留 为什么      更新时间：2023-10-16

我知道这是一个古老的功能，但阅读用户定义的文字，例如

return_t operator "" _a(long); // Literal operator for user-defined INTEGRAL literal

有人提醒我

前导下划线是必需的。（仅允许标准库定义不带下划线的文本。（一）

这似乎打破了模式，因为到目前为止，该实现使用下划线名称并留给我们留下了好名称，例如保留给实现的名称

  1. 包含双下划线
  2. 以下划线开头，后跟大写字母

此外，在规则（2）存在的情况下，引用（A）有些危险。那么为什么不一致呢？

在将用户定义的文字的概念添加到语言之前，所有标准文字都使用不以下划线开头的序列，例如123L表示long int文字。因此，为了保持一致性，标准文本获取没有任何特殊前缀的命名空间，并且通过使用 _ 将 UDL 与它们区分开来。

相关文章：