默认情况下，为什么全局名称空间中不包含C++ 14标准定义的文字？

C++ 14包含标准定义的文字，其中包括std::string和<chrono>标题中的各种时间片段。默认情况下，为什么全局名称空间中不包含C++ 14标准定义的文字？

要使用它们，您必须说using namespace std::literals;（或者由于它们在各种内联命名空间中，所以需要根据所需的字面值进行一些变化）。

这一切都很好，但我很好奇为什么using声明是必需的。没有前导下划线的UDL被保留用于执行，因此不可能在符合标准的程序中意味着任何其他内容。

那么为什么#include <string>不足以将文字转换函数带入范围呢？为什么我必须明确包含文字命名空间？

编辑：N3531是最近的我能找到的提案版本 - 遗憾的是它不讨论动机把事情的命名空间，但只说：

人们可以总结的[波特兰]讨论的要求如下：

使用直列命名空间一个（组相关的）UDL运营商（多个）

2014-10-27 Tristan Brindle

可能出于同样的原因，用户定义的文字必须以'_'开始：[forward compatibility]（http://en.wikipedia.org/wiki/Forward_compatibility）。他们预计将来会在某些时候添加更多的文字，我想他们会将它们放在不同的名称空间中以避免命名冲突。 – Cornstalks 2014-10-27 14:56:34

@关闭选民：我非常怀疑这是基于意见的。标准委员会做出了决定。这是问*为什么他们做出了他们所做的决定。这不是基于意见。它基于事实上在委员会内的历史讨论和决定。 – Cornstalks 2014-10-27 14:58:48

“不带前导下划线的UDL被保留用于实现”哪里以及在哪个版本中？ – 2014-10-27 15:03:13

已经有两个名为s的UDL：一个用于字符串，另一个用于seconds。由于可以理解的后缀名称简短，它们长期遭受名称冲突，所以将它们全部注入一个名称空间不会很长时间。因此决定将它们放入内联命名空间，这允许明确的（using namespace std::literals::chrono_literals）和简单的using指令（using namespace std）。

来源

2014-10-27 14:58:51 Columbo

在全局名称空间中永远不会有其他's'后缀，因为所有非标准的UDL都必须以下划线开头。 – 2014-10-27 15:04:47

@TristanBrindle ...想象一下，为了这个论点，标准委员会本身想要引入第二个“运算符”“s”。 – Columbo 2014-10-27 15:05:46

@TristanBrindle：这里有三个利益相关者：标准，平台/实现/系统库和最终开发者。只有最后一个禁止使用没有前导下划线的UDL后缀。 – 2014-10-27 15:06:40

看看纸N2765。 UDL挂钩到常规名称查找过程中。由于字符串文字具有常见的字符串类型，因此如果忽略命名空间，则很可能会发生冲突。

来源

2014-10-27 14:57:55 MSalters

标准库中已经定义了什么s可能意味着多个版本：

它可以用来定义一个字符串。
它可以用来定义一个chrono::seconds文字。

一个基于字符串文字，一个基于整数或文字，当然，即它们实际上可以共存。但是，我预计未来可能会有更多的使用s。因此，必须选择导入哪些名称空间而不是强加给你，似乎是一种合理的方法。

来源

2014-10-27 15:00:08

默认情况下，为什么全局名称空间中不包含C++ 14标准定义的文字？

回答

相关问题