用户定义的字面后缀，带* _digit ...“？

甲用户定义字面后缀 C++ 0x中应该是一个标识符该用户定义的字面后缀，带* _digit ...“？

开始于_（下划线）（ 17.6.4.3.5）
应该不与_开始后跟大写字母（17.6.4.3.2）

每个名称[...]以下划线跟着是一个大写字母开头被保留执行任何使用。

是否有任何理由，为什么这样的后缀可能无法启动_后面跟着一个数字？ I.E. _4或_3musketeers？

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

来源

2011-04-25 towi

规范说“每个名字......”。用户定义的文字操作符名称就像'operator“”_Foo“。这里没有名字像'_Foo'拼写，所以17.6.4.3.2不适用。我还想知道，你从哪里读到后缀可能不是以'_'开头，后面跟着一个数字？我还没有找到这样的规则。 – 2011-04-25 11:46:32

嗯，我想我忽略了库也允许impl使用'_Foo'作为宏，所以使用'operator“”_Foo“不安全。 – 2011-04-25 14:56:04

我在那里给了参考。 '_Xxx'和'__anything'被保留用于所有地方的实现，全局名称空间中的'_anything'。 – towi 2011-04-26 07:20:38

_<number>表单的标识符的先例是std::placeholders（§20.8.9.1.3）中的函数参数占位符对象机制，该机制定义了此类符号的实现定义数目。

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

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

用户定义的字面函数的名称是operator "" _123，不是简单_123，所以你的名字和库名之间没有直接的冲突，如果using namespace std::placeholders;的存在。

我的2¢，但是，你会更好用operator "" _baseconv和编码字面内的基地，"123123_4"_baseconv。

编辑： ~~纵观约翰内斯（删除）的答案，有~~ 有可能是担心，_123可以通过实施被用作宏。这当然是理论的领域，因为这种预处理器的使用几乎没有实现。此外，如果我没有弄错，在std::placeholders而不是std本身中隐藏这些符号的原因是这些名称是更多的可能被用户使用，例如通过包含升压绑定（其不确定）将它们隐藏在命名的命名空间内）。

这些令牌不是为全局实现（17.6.4.3.2）而使用的，它们有使用的先例，所以它们至少与forward一样安全。

来源

2011-04-26 20:10:19 Potatoswatter

我的意思是我的担心是它是否可以使用'_N'作为宏（我的意思是'N'，不是数字），因为'_N'或'__n'是“保留用于任何用途”。例如，确定一个'运算符“”_WIN32“不是一个好主意，同样适用于使用'_Vector'的尾随示例。 :) – 2011-04-26 20:46:38

@Johannes：哦。这有什么关系？ – Potatoswatter 2011-04-26 21:12:23

@Patatoswatter我以为你说'运营商'“_2'很好。我想澄清一下，我并不是故意说“操作符”“_2”是被禁止的，我并不是想说'_2'可能有宏。也就是说，“看着约翰内斯（已删除）的答案，有人担心实施时可能会使用_123作为宏。”，只是想澄清一下，如果存在这样的担忧，问题不是来自我的。 – 2011-04-26 21:23:22

“罐” VS “可”。
可以表示能力，其中可能表示许可。

你有没有权限启动用户定义的文字后缀_后跟数字？

权限意味着编码标准或最佳实践。你提供的例子似乎表明_\d将罚款后缀，如果使用正确（表示数字基地）。不幸的是，你的问题不能有一个深思熟虑的答案，因为没有人有这种新的语言功能的经验。

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

来源

2011-04-25 15:04:28

打扰我的草率配方。当然，在标准文本中“可能”和“可以”具有严格的含义。据我所知，*还不能成为最佳实践，因为仍然有支持用户定义文字的编译器。至少gcc 4.7.0没有。但是很高兴知道您还阅读了“_ \ d”是......“* valid *”的文字。而从其他限制中我也看不到“*劝阻*”。 – towi 2011-04-26 07:15:13

下划线后跟数字是合法的用户定义文字后缀。函数签名将为： 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-27 03:11:14 emsr

我经常写'10 * 1000 * 1000 * 1000'来显示大数字（有很多'0'）。但是不要写'123 * 456 * 789'，但:-) – towi 2011-04-27 07:18:13

'123123_4'是一个预处理器令牌，非常好！但''123123“_4'不是。所以，没有帮助。但我仍然认为，因为占位符在'std ::'中，所以我们在这里不应该有问题。我仍然不知道在* global *命名空间中的_ _ （不在'std ::'中） – towi 2011-04-27 07:20:31

根据标准和根据正在gcc中编译的实现“123123”_4 * will *成为一个新的预处理器令牌 – emsr 2011-04-27 19:37:38

我知道我对这个问题的一些论文： Digital Separators描述了使用建议_和数字的文字

Ambiguity and Insecurity with User-Defined literals一个数字分隔介绍的有关文字后缀命名和命名空间的预留和努力演进思路根据未来的数字分隔符解除冲突用户定义的文字。

它只是看起来不是很好的_数位分隔符。

我有一个想法，但如何反斜杠或数位分隔符反向？它不如_好，但我认为只要反斜杠位于数字流内，就不会有任何碰撞。当前我所知道的反向词汇没有词汇用法。

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

或

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

这将使_123作为文字后缀。

来源

2011-07-01 06:30:11 emsr

用户定义的字面后缀，带* _digit ...“？

回答

相关问题