为什么chrono有自己的名称空间？ [英] Why does chrono have its own namespace?

问题描述

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

Everything else I have seen so far in the C++ standard library is in the std namespace. If I use things from std::chrono I usually exceed my 80 character per line limit - that is not a problem, just inconvienent.

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

So here my simple question: Why does the chrono header has its own namespace?

推荐答案

chrono提案的作者。子命名空间不是我的首选，只是因为冗长。我发现自己几乎每次使用该功能时都使用命名空间std :: chrono 来编写。

I was lead author on the chrono proposal. A sub-namespace was not my first choice, just because of the verbosity. I find myself writing using namespace std::chrono almost every time I use the facility.

但是这是一个非常有争议的建议。许多人，包括我的一些合著者，都强烈认为子命名空间是适当的。我并不强烈反对该子命名空间，因为我们处于一个需要妥协的空间，或者像美国国会一样陷入僵局。 ：⁠-⁠）这种死锁的结果可能是C11的 timespec 。

However this was a very controversial proposal. And many people, including some of my co-authors strongly felt that a sub-namespace was appropriate. I did not strongly object to the sub-namespace because we were in a space of needing to compromise, or become just as dead-locked as the US congress. :⁠-⁠) The result of such a dead-lock would have probably been C11's timespec.

boost有对子命名空间进行了比std更为激进的实验，本文的主要作者之一还是chrono所基于的boost date-time库的作者。这样显然会在使用子命名空间的方向上产生强大的吸引力。

boost has experimented with sub-namespaces much more aggressively than the std has and one of the key authors on this paper is also the author of the boost date-time library upon which chrono evolved from. So that would obviously have a strong pull in the direction of using a sub-namespace.

展望未来，子命名空间很有可能会成为绝对必需的。想象一下，如果我们添加日历服务，其中包括12月的缩写： dec 。这将直接与以下内容冲突：

Looking forward it is quite possible that the sub-namespace will become absolutely required. Imagine if we add calendrical services that include an abbreviation for December: dec. This would directly conflict with:

ios_base& dec(ios_base& str);

在< ios> 中。因此，总的来说，我从一开始就不坚持使用子命名空间可能是错误的。 ：⁠-⁠）向前看，观察委员会在哪里创建和不创建子命名空间很有趣。

in <ios>. So all in all, I was probably wrong in not insisting on a sub-namespace from the beginning. :⁠-⁠) Going forward it will be interesting to watch where the committee does and does not create sub-namespaces.

更新（6年后。 ）

真相总是比小说更陌生...

The truth is always stranger than fiction...

所以我 did 建议 std :: chrono :: dec 作为 12月的缩写，之所以安全，是因为嵌套了 chrono 命名空间。但是，委员会决定将 std :: chrono :: dec 重命名为 std :: chrono :: December

So I did propose std::chrono::dec as an abbreviation for December, thinking that would be safe because of the nested chrono namespace. But no, the committee decided to rename std::chrono::dec to std::chrono::December during the standardization process because of potential conflicts.

嵌套名称空间值得吗？

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

I don't know. This update is a datapoint, not an opinion.

这篇关于为什么chrono有自己的名称空间？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！