到目前为止,我在 C++ 标准库中看到的所有其他内容都在 std
中。命名空间。如果我使用来自 std::chrono
的东西我通常会超过每行 80 个字符的限制——这不是问题,只是不方便。
所以这里是我的简单问题:为什么 chrono header 有自己的命名空间?
最佳答案
我是 chrono proposal 的主要作者.子命名空间不是我的首选,只是因为冗长。我发现自己在写作 using namespace std::chrono
几乎每次我使用该设施。
然而,这是一个非常有争议的提议。许多人,包括我的一些合著者,强烈认为子命名空间是合适的。我没有强烈反对子命名空间,因为我们处于需要妥协的空间,或者像美国国会一样陷入僵局。 :-) 这种死锁的结果可能是 C11 的 timespec
.
boost 比 std 更积极地试验了子命名空间,本文的主要作者之一也是 boost 日期时间库的作者,chrono 正是基于该库发展而来的。所以这显然会对使用子命名空间产生强烈的插入作用。
展望 future ,子命名空间很有可能成为绝对必需的。想象一下,如果我们添加包含十二月缩写的日历服务:dec
.这将直接与以下内容冲突:
ios_base& dec(ios_base& str);
在
<ios>
.总而言之,我从一开始就没有坚持使用子命名空间可能是错误的。 :-) 展望 future ,观察委员会在哪里创建和不创建子命名空间会很有趣。更新(6 年后...)
真相永远比小说离奇……
所以我确实提出了
std::chrono::dec
作为 December
的缩写,认为这是安全的,因为嵌套 chrono
命名空间。但是没有,委员会决定重命名std::chrono::dec
至 std::chrono::December
由于潜在的冲突,在标准化过程中。那么嵌套命名空间值得吗?
我不知道。此更新是一个数据点,而不是一个意见。
关于c++ - 为什么 chrono 有自己的命名空间?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42362870/