1

C ++0x中用户定义的文字后缀应该是一个标识符

  • 以_（下划线）开头（17.6.4.3.5）
  • 不应以大写字母开头(17.6.4.3.2 )_

    [...] 以下划线后跟大写字母开头的每个名称都保留给实现以供任何使用。

有什么理由，为什么这样的后缀不能_ 以数字开头？IE_4或_3musketeers?

Musketeer dartagnan = "d'Artagnan"_3musketeers;
int num = 123123_4; // to be interpreted in base4 system?
string s = "gdDadndJdOhsl2"_64; // base64decoder
4

4 回答 4

1

“可以”与“可能”。
can表示能力，may表示许可。

您是否有理由无权以 _ 后跟数字开始用户定义的文字后缀？

许可意味着编码标准或最佳实践。您提供的示例似乎表明，_\d如果使用正确（表示数字基数），后缀会很好。不幸的是，您的问题没有经过深思熟虑的答案，因为目前还没有人使用过这种新的语言功能。

只是要清楚user-defined literal suffixes 可以开始_\d。

于 2011-04-25T15:04:28.103 回答
1

形式标识符的先例_<number>是（第 20.8.9.1.3 节）中的函数参数占位符对象机制std::placeholders，它定义了实现定义的此类符号的数量。

这是一件好事，因为这意味着用户无法#define获得该表单的任何标识符。§17.6.4.3.1/1：

包含标准库头文件的翻译单元不得在任何标准库头文件中声明#define 或#undef 名称。

用户定义的文字函数的名称operator "" _123不是简单_123的，因此如果存在using namespace std::placeholders;.

不过，我的 2 美分是，您最好operator "" _baseconv在文字中使用和编码基数，"123123_4"_baseconv.

编辑： 查看 Johannes 的（已删除）答案，可能存在可能被_123实现用作宏的问题。这当然是理论上的领域，因为这种预处理器的使用对实现几乎没有好处。此外，如果我没记错的话，将这些符号隐藏在 中std::placeholders而不是std其本身的原因是用户更有可能使用这些名称，例如通过包含 Boost Bind （它不会将它们隐藏在命名的命名空间）。

令牌不保留供全局实现使用（17.6.4.3.2），并且它们的使用有先例，因此它们至少与forward.

于 2011-04-26T20:10:19.193 回答
1

下划线后跟数字是合法的用户定义的文字后缀。函数签名将是：operator"" _4(); 所以它不能被占位符吃掉。文字将是单个预处理器标记：123123_4; 所以 _4 不会被占位符或预处理器符号破坏。

我对 17.6.4.3.5 的解读是，不包含前导下划线的后缀可能会与实现或未来的库添加发生冲突。它们还与现有后缀发生冲突：F、L、ULL 等。用户定义文字的基本原理之一是可以将新类型（例如小数）定义为纯库扩展，包括带有后缀 d 的文字， df，dl。

然后是风格和可读性的问题。就个人而言，我认为我会忽略后缀 1234_3；也许，也许不是。

最后，有一些想法没有成为标准（但我有点喜欢）让 _ 成为像 Ada 和 Ruby 中的数字的文字分隔符。因此，例如，您可以使用 123_456_789 在视觉上分隔数千。如果它通过的话，你的后缀会被破坏。

于 2011-04-27T03:11:14.350 回答
1

我知道我有一些关于这个主题的论文： Digital Separators描述了使用 _ as a digit separator in numeric literals 的提议

用户定义的文字的歧义和不安全性描述了有关文字后缀命名和命名空间保留的想法的演变，以及消除用户定义文字与未来数字分隔符冲突的努力。

_ 数字分隔符看起来不太好。

不过我有一个想法：反斜杠或反引号用于数字分隔符怎么样？它不如 _ 好，但我认为只要反斜杠在数字流内，就不会有任何冲突。据我所知，反引号目前没有词汇用途。

i = 123\456\789;
j = 0xface\beef;

或者

i = 123`456`789;
j = 0xface`beef;

这将使 _123 作为文字后缀。

于 2011-07-01T06:30:11.893 回答