用户定义的文字后缀，带有 *_digit...”？
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
A user-defined literal suffix in C++0x should be an identifier that
- starts with
_(underscore) (17.6.4.3.5) - should not begin with
_followed by uppercase letter (17.6.4.3.2)Each name that [...] begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
Is there any reason, why such a suffix may not start _ followed by a digit? I.E. _4 or _3musketeers?
Musketeer dartagnan = "d'Artagnan"_3musketeers;
int num = 123123_4; // to be interpreted in base4 system?
string s = "gdDadndJdOhsl2"_64; // base64decoder
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
_形式的标识符的先例是std::placeholders中的函数参数占位符对象机制（第 20.8.9.1.3 节），它定义了一个实现- 定义数量的此类符号。这是一件好事，因为这意味着用户无法
#define该表单的任何标识符。 §17.6.4.3.1/1：用户定义的文字函数的名称是
operator "" _123，而不是简单的_123，因此如果存在使用命名空间 std::placeholders;。不过，我的2美分是，您最好使用
运算符“”_baseconv并在文字“123123_4”_baseconv中对基数进行编码。编辑：
查看 Johannes（已删除）的答案，可能有人担心_123可能被用作宏 实施。这当然是理论领域，因为这种预处理器的使用对实现几乎没有什么好处。此外，如果我没记错的话，将这些符号隐藏在std::placeholders中而不是std本身的原因是这些名称更多 可能被用户使用，例如通过包含 Boost Bind（这不会将它们隐藏在命名空间内）。这些令牌不保留供全局实现使用 (17.6.4.3.2)，并且它们的使用有先例，因此它们至少与
forward一样安全。The precedent for identifiers of the form
_<number>is the function argument placeholder object mechanism instd::placeholders(§20.8.9.1.3), which defines an implementation-defined number of such symbols.This is a good thing, because it means the user cannot
#defineany identifier of that form. §17.6.4.3.1/1:The name of the user-defined literal function is
operator "" _123, not simply_123, so there is no direct conflict between your name and the library name if presence of theusing namespace std::placeholders;.My 2¢, though, is that you would be better off with an
operator "" _baseconvand encoding the base within the literal,"123123_4"_baseconv.Edit:
Looking at Johannes' (deleted) answer, there isThere may be concern that_123could be used as a macro by the implementation. This is certainly the realm of theory, as the implementation would have little to gain by such preprocessor use. Furthermore, if I'm not mistaken, the reason for hiding these symbols instd::placeholders, notstditself, is that such names are more likely to be used by the user, such as by inclusion of Boost Bind (which does not hide them inside a named namespace).The tokens are not reserved for use by the implementation globally (17.6.4.3.2), and there is precedent for their use, so they are at least as safe as, say,
forward.“可以” vs “可能”。
can 表示能力，may 表示许可。
许可意味着编码标准或最佳实践。您提供的示例似乎表明，如果使用正确（表示数字基数），
_\d会很好的后缀。不幸的是，您的问题无法得到深思熟虑的答案，因为还没有人有使用这一新语言功能的经验。需要明确的是，
用户定义的文字后缀可以以_\d开头。"can" vs "may".
can denotes ability where may denotes permission.
Permission implies coding standards or best-practices. The examples you provides seem to show that
_\dwould fine suffixes if used correctly (to denote numeric base). Unfortunately your question can't have a well thought out answer as no one has experience with this new language feature yet.Just to be clear
user-defined literal suffixescan start with_\d.下划线后跟数字是合法的用户定义的文字后缀。
函数签名为：
运算符"" _4();
所以它不能被占位符吃掉。
文字将是一个单个预处理器标记：
123123_4；
因此 _4 不会被占位符或预处理器符号破坏。
我对 17.6.4.3.5 的解读是，不包含前导下划线的后缀存在与实现或未来库添加发生冲突的风险。它们还与现有后缀发生冲突：F、L、ULL 等。用户定义文字的基本原理之一是新类型（例如小数）可以定义为纯库扩展，包括带有后缀 d 的文字， df、dl。
然后是风格和可读性的问题。就我个人而言，我认为我会忽略后缀 1234_3；也许，也许不是。
最后，有一些想法没有进入标准（但我有点喜欢），让 _ 作为数字的文字分隔符，就像 Ada 和 Ruby 中那样。例如，您可以使用 123_456_789 在视觉上分隔数千个。如果发生这种情况，你的后缀就会被破坏。
An underscore followed by a digit is a legal user-defined literal suffix.
The function signature would be:
operator"" _4();
so it couldn;t get eaten by a placeholder.
The literal would be a single preprocessor token:
123123_4;
so the _4 would not get clobbered by a placeholder or a preprocessor symbol.
My reading of 17.6.4.3.5 is that suffixes not containing a leading underscore risk collision with the implementation or future library additions. They also collide with existing suffixes: F, L, ULL, etc. One of the rationales for user-defined literals is that a new type (such as decimals for example) could be defined as a pure library extension including literals with suffuxes d, df, dl.
Then there's the question of style and readability. Personally, I think I would loose sight of the suffix 1234_3; Maybe, maybe not.
Finally, there was some idea that didn't make it into the standard (but I kind of like) to have _ be a literal separator for numbers like in Ada and Ruby. So you could have 123_456_789 to visually separate thousands for example. Your suffix would break if that ever went through.
我知道我有一些关于这个主题的论文：
数字分隔符描述了使用的建议_ 作为数字文字中的数字分隔符
歧义和不安全性与用户定义的文字 描述有关文字后缀命名和命名空间保留的想法的演变，以及消除用户定义的文字与未来数字分隔符的冲突的努力。
对于 _ 数字分隔符来说，它看起来不太好。
不过我有一个想法：数字分隔符用反斜杠或反引号怎么样？它不如 _ 那么好，但我认为只要反斜杠位于数字流内，就不会有任何冲突。据我所知，反引号目前没有词汇用途。
或者
这会将 _123 保留为文字后缀。
I knew I had some papers on this subject:
Digital Separators describes a proposal to use _ as a digit separator in numeric literals
Ambiguity and Insecurity with User-Defined literals Describes the evolution of ideas about literal suffix naming and namespace reservation and efforts to deconflict user-defined literals against a future digit separator.
It just doesn't look that good for the _ digit separator.
I had an idea though: how about either a backslash or a backtick for digit separator? It isn't as nice as _ but I don't think there would be any collision as long as the backslash was inside the stream of digits. The backtick has no lexical use currently that I know of.
or
This would leave _123 as a literal suffix.