18

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.

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

bames53
  • 86,085
  • 15
  • 179
  • 244
cschwan
  • 3,283
  • 3
  • 22
  • 32
  • 13
    Ditch the 80 character limit, this isn't the 80s anymore. – GManNickG Nov 18 '12 at 18:56
  • 3
    I actually introduced the limit for myself after not using one before. If you open a debugger to your left on a laptop with a limited screen width it is fairly useful. Also in the rare case when you print out your code. In general, I think code that does not fit into a single 80-character line is less readable, see for example some of Java's library interfaces ;) – cschwan Nov 18 '12 at 21:06
  • You'll be much better off if you deal with it on a case-by-case basis. If fitting the line into 80 characters forces you to introduce awkward breaks, don't do it. If breaking a line at character 23 makes it easier to read, do it. There's no single number. – GManNickG Nov 19 '12 at 03:47
  • 2
    Or just, you know, `namespace sc = std::chrono;` – KitsuneYMG Nov 19 '12 at 15:16
  • 2
    Since it's now the 2010's, the new limit is 2010-1900 = 110 characters per line ;) – wjl Nov 20 '12 at 01:57
  • 1
    [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html#Line_Length) reads: "Each line of text in your code should be at most 80 characters long." – kevinarpe Aug 02 '16 at 04:22

2 Answers2

32

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.

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 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.

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);

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.

Update (6 years later...)

The truth is always stranger than fiction...

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.

So are nested namespaces worth it?

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

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • Will there be a push to move existing libraries in their own sub-namespaces for consistency, but also put them in `std` (for backwards compatibility)? General best practice is usually not to use `using namespace`. Will sub-namespaces under `std` change this, and is that a good thing? There are legitimate reasons not to use it, but `chrono` is too cumbersome without `using namespace std::chrono`. – David Feb 27 '13 at 21:42
  • @Dave: The future is always hard to predict (especially when talking about what the committee will do), but I doubt the committee will retrofit sub-namespaces onto existing signatures. – Howard Hinnant Feb 28 '13 at 00:13
  • @HowardHinnant, I've a [question](https://stackoverflow.com/q/44269533/213871) regarding `time_point` and `duration` classes internal storage limitations – ceztko May 30 '17 at 18:41
  • @HowardHinnant, just curious, but why was chrono a "very controversial proposal?" (And thanks for helping to author it, by the way.) – Dan Jun 28 '18 at 18:23
  • 1
    @Dan. A significant number of people on the committee wanted to standardize the POSIX `timespec` (a `struct` with a field for seconds and a field for nanoseconds). This solution was simple, and had loads of field experience. And it has C compatibility. When [N2661](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm) was written, that was the audience I was writing for. When contrasted with vastly more complicated `` specification, it was not an easy sell. I tried to emphasize that the _user's_ experience would be simpler and less error prone. – Howard Hinnant Jun 28 '18 at 19:06
  • @HowardHinnant, that's interesting. Thanks for the reply. – Dan Jun 29 '18 at 13:13
7

There are other namespaces too, like std::placeholders. Ultimately, in C++03 the Committee did not go for subnamespaces, but it is now painfully obvious that the std namespace is becoming massively overloaded. As such, I expect that many library proposals for C++14 will use a subnamespace for larger organizations of components.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Could you elaborate a bit more on "massively overloaded"? I mean, it is true that with C++11 the standard library is growing and along with that also the members in the `std` namespace. But I do not see a reason why putting e.g. `a` into `std::subnamespace` if there is no `a` in `std` yet. – cschwan Nov 18 '12 at 14:02
  • 3
    Because then you end up with `std::a` and `std::sub::a`, instead of `std::sub1::a` and `std::sub2::a`. More importantly, there's simply a whole bunch of `a` already used. – Puppy Nov 18 '12 at 15:00