c++ - 为什么 chrono 有自己的命名空间？

Question

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

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

Answer 1

我是计时提案的主要作者。子命名空间不是我的第一选择，只是因为冗长。我发现自己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

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

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

Answer 2

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