到目前为止，我在C++标准库中看到的所有其他内容都在std命名空间中。如果我使用std::chrono中的东西，我通常会超过每行80个字符的限制——这不是问题，只是不方便。
所以这里我有一个简单的问题：为什么chrono标头有自己的名称空间？
我是chrono提案的主要作者。子名称空间不是我的第一选择，只是因为冗长。我发现自己几乎每次使用using namespace std::chrono。
然而，这是一个极具争议的提议。许多人，包括我的一些合著者，强烈认为子命名空间是合适的。我并不强烈反对子名称空间，因为我们正处于一个需要妥协的空间，或者变得像美国国会一样陷入僵局-；)这种死锁的结果可能是C11的timespec。
boost比std更积极地尝试了子名称空间，本文的主要作者之一也是chrono的boost日期-时间库的作者。因此，这显然会对使用子命名空间产生很大的影响。
展望未来，子名称空间很可能成为绝对需要的。想象一下，如果我们添加日历服务，其中包括十二月的缩写：dec。这将与直接冲突
ios_base& dec(ios_base& str);
在CCD_ 6中。总而言之，我从一开始就没有坚持使用子命名空间，这可能是错误的-；)展望未来，观察委员会在哪里创建子名称空间和不创建子名称名称空间将是一件有趣的事情。
更新(6年后…)
真相总是比小说更离奇。。。
因此，我确实提出了std::chrono::dec作为December的缩写，认为由于嵌套的chrono命名空间，这是安全的。但没有，由于潜在的冲突，委员会决定在标准化过程中将std::chrono::dec重命名为std::chrono::December。
那么嵌套的名称空间值得吗？
我不知道。这次更新是一个数据点，而不是意见。
还有其他名称空间，如std::placeholders。最终，在C++03中，委员会没有选择次命名空间，但现在很明显，std命名空间正变得严重过载。因此，我预计许多针对C++14的库提案将为更大的组件组织使用次中心空间。