为什么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的许多库提议将为更大的组件组织使用子名称空间.