为什么 chrono 有自己的命名空间？答案

【问题标题】：Why does chrono have its own namespace?为什么 chrono 有自己的命名空间？
【发布时间】：2012-11-06 12:35:53
【问题描述】：

到目前为止，我在 C++ 标准库中看到的所有其他内容都在 std 命名空间中。如果我使用来自 std::chrono 的东西，我通常会超过每行 80 个字符的限制 - 这不是问题，只是不方便。

所以这里是我的简单问题：为什么 chrono 标头有自己的命名空间？

【问题讨论】：

放弃 80 个字符的限制，这不再是 80 年代了。
我其实是在之前没用过限制后给自己介绍的。如果您在屏幕宽度有限的笔记本电脑上打开左侧的调试器，它会非常有用。在您打印代码时也是如此。一般来说，我认为不适合单个 80 个字符行的代码可读性较差，例如，请参阅 Java 的一些库接口；）
或者只是，你知道，namespace sc = std::chrono;
现在是 2010 年代，新的限制是 2010-1900 = 每行 110 个字符 ;)
Google C++ Style Guide 写道：“代码中的每一行文本最多应包含 80 个字符。”

【解决方案1】：

我是chrono proposal 的主要作者。子命名空间不是我的第一选择，只是因为冗长。我发现自己几乎每次使用该设施时都会写using namespace std::chrono。

然而，这是一个非常有争议的提议。许多人，包括我的一些合著者，强烈认为子命名空间是合适的。我没有强烈反对子命名空间，因为我们处于需要妥协的空间，或者像美国国会一样陷入僵局。 :⁠-⁠) 这种死锁的结果可能是 C11 的timespec。

boost 比 std 更积极地尝试子命名空间，本文的主要作者之一也是 chrono 演变而来的 boost 日期时间库的作者。所以这显然会对使用子命名空间有很大的吸引力。

展望未来，子命名空间很可能会成为绝对必需的。想象一下，如果我们添加包含 12 月缩写的日历服务：dec。这将直接与：

ios_base& dec(ios_base& str);

在<ios>。所以总而言之，我从一开始就没有坚持使用子命名空间可能是错误的。 :⁠-⁠) 展望未来，看看委员会在哪里创建子命名空间和不创建子命名空间会很有趣。

更新（6 年后...）

真相总是比小说离奇......

所以我确实建议将std::chrono::dec 用作December 的缩写，认为由于嵌套了chrono 命名空间，这将是安全的。但是没有，由于潜在的冲突，委员会决定在标准化过程中将std::chrono::dec 重命名为std::chrono::December。

那么嵌套命名空间值得吗？

我不知道。此更新是数据点，而不是意见。

【讨论】：

是否会推动将现有库移动到它们自己的子命名空间中以保持一致性，同时将它们放入std（为了向后兼容）？一般的最佳实践通常是不使用using namespace。 std 下的子命名空间会改变这一点，这是一件好事吗？有正当理由不使用它，但chrono 没有using namespace std::chrono 太麻烦了。
@Dave：未来总是难以预测（尤其是在谈论委员会将做什么时），但我怀疑委员会会将子命名空间改造到现有签名上。
@HowardHinnant，我有一个关于 time_point 和 duration 类内部存储限制的 question
@HowardHinnant，只是好奇，但为什么 chrono 是一个“非常有争议的提案”？（顺便说一句，感谢您帮助创作它。）
@丹。委员会中有相当多的人希望标准化 POSIX timespec（struct 具有秒字段和纳秒字段）。这个解决方案很简单，并且有大量的现场经验。它具有 C 兼容性。当N2661 写出来的时候，那是我写的读者。与复杂得多的<chrono> 规范相比，它并不容易出售。我试图强调用户的体验会更简单，更不容易出错。

【解决方案2】：

还有其他命名空间，例如std::placeholders。最终，在 C++03 中，委员会没有选择子命名空间，但现在很明显std 命名空间正变得严重超载。因此，我希望 C++14 的许多库提案将使用子命名空间来用于更大的组件组织。

【讨论】：

您能否详细说明“大规模过载”？我的意思是，随着 C++11 标准库的增长，std 命名空间中的成员也随之增长。但是我看不出为什么要放例如如果std 中还没有a，则将a 转换为std::subnamespace。
因为那样你会得到std::a 和std::sub::a，而不是std::sub1::a 和std::sub2::a。更重要的是，已经使用了一大堆a。