用户定义的文字后缀,带* _digit…\\“?

|| C ++ 0x中用户定义的文字后缀应为以下标识符: 以
_
(下划线)(17.6.4.3.5)开头 不应以“ 0”开头,后跟大写字母(17.6.4.3.2)   带有下划线和大写字母开头的每个名称都保留给实现以供任何使用。    有什么原因,为什么这样的后缀不能以“ 0”开头,后跟数字?即
_4
还是
_3musketeers
Musketeer dartagnan = \"d\'Artagnan\"_3musketeers;
int num = 123123_4; // to be interpreted in base4 system?
string s = \"gdDadndJdOhsl2\"_64; // base64decoder
    
已邀请:
形式为“ 6”的标识符的先例是“ 7”(第20.8.9.1.3节)中的函数参数占位符对象机制,它定义了此类符号的实现定义数量。 这是一件好事,因为这意味着用户无法“ 8”该格式的任何标识符。 §17.6.4.3.1/ 1:   包含标准库头的翻译单元不得在任何标准库头中声明的#define或#undef名称。 用户定义的文字函数的名称是
operator \"\" _123
,而不仅仅是
_123
,因此,如果存在
using namespace std::placeholders;
,则您的名称和库名称之间没有直接冲突。 不过,我的2美分是,最好使用
operator \"\" _baseconv
,并在文字
\"123123_4\"_baseconv
中编码基数。 编辑:查看Johannes的(已删除)答案,可能存在实现可能将“ 10”用作宏的问题。这当然是理论上的领域,因为这种预处理器的使用几乎无法获得实现。此外,如果我没记错的话,将这些符号隐藏在“ 7”而不是“ 16”本身中的原因是,这样的名称更可能被用户使用,例如通过包含Boost Bind(不会隐藏它们)命名空间中)。 令牌不保留供全局实现使用(17.6.4.3.2),并且有使用令牌的先例,因此它们至少与“ѭ17”一样安全。     
\“可以\”与\“可以\”。 可以表示能力,可以表示许可。   有没有理由为什么您没有权限以_后跟数字开头的用户定义文字后缀? 许可意味着编码标准或最佳实践。您提供的示例似乎表明,如果正确使用(表示数字基数),则
_\\d
会更适合后缀。不幸的是,您的问题还没有经过深思熟虑的答案,因为还没有人使用此新语言功能。 为了清楚起见,
user-defined literal suffixes
可以以with18ѭ开头。     
下划线后跟数字是合法的用户定义的文字后缀。 函数签名为: 运算符\“ \” _4(); 因此它不能被占位符吃掉。 文字将是单个预处理器令牌: 123123_4; 因此_4不会被占位符或预处理器符号所破坏。 我对17.6.4.3.5的阅读是,不包含下划线的后缀可能会与实现或将来的库添加冲突。它们还会与现有的后缀F,L,ULL等冲突。用户定义的文字的基本原理之一是,可以将新类型(例如小数)定义为纯库扩展名,包括带后缀d的文字。 df,dl。 然后是样式和可读性的问题。我个人认为后缀1234_3会让我看不清;也许吧,也许不是。 最后,有一个想法并没有使_成为Ada和Ruby之类的数字的文字分隔符(但我有点喜欢)。因此,您可以使用123_456_789从视觉上分离数千个。如果经过,您的后缀将中断。     
我知道我有一些关于这个主题的论文: 数字分隔符描述了在数字文字中使用_作为数字分隔符的建议 用户定义的文字的歧义和不安全性描述了有关文字后缀命名和名称空间保留的思想的演变,以及努力使用户定义的文字与将来的数字分隔符冲突。 _数字分隔符看起来不太好。 我有个主意:数字分隔符的反斜杠或反引号怎么样?它不如_好,但我认为只要反斜杠位于数字流中就不会发生任何冲突。据我所知,反引号目前没有词汇用法。
i = 123\\456\\789;
j = 0xface\\beef;
要么
i = 123`456`789;
j = 0xface`beef;
这将_123保留为原义后缀。     

要回复问题请先登录注册