Question

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

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

Answer 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。

嵌套命名空间值得吗？

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

Answer 2

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