7

The C++ Draft par 20.12.7.3 reads:

high_resolution_clock may be a synonym for system_clock or steady_clock

Of course this may mandates nothing but I wonder :

  • Is there any point for high_resolution_clock to something other that a typedef ?
  • Are there such implementations ?
  • If a clock with a shorter tick period is devised it can either be steady or not steady. So if such a mechanism exists, wouldn't we want to "improve" system_clock and high_resolution_clock as well, defaulting to the typedef solution once more ?
Lorah Attkins
  • 5,331
  • 3
  • 29
  • 63
  • "Is there any point for `high_resolution_clock` to something other that a typedef?" Preventing you from non-portably mixing time points of different clocks, perhaps? – T.C. Feb 28 '16 at 12:35
  • @T.C.It's a typedef in every existing implementation though. So what you say only highlights an existing possible problem. – Lorah Attkins Feb 28 '16 at 18:38

1 Answers1

4

The reason that specs have wording such as "may" and "can", and other vague words that allow for other possibilities comes from the wish by the spec writers not wanting to (unnecessarily) limit the implementation of a "better" solution of something.

Imagine a system where time in general is counted in seconds, and the system_clock is just that - the system_clock::period will return 1 second. This time is stored as a single 64-bit integer.

Now, in the same system, there is also a time in nano-seconds, but it's stored as a 128-bit integer. The resulting time-calculations are slightly more complex due to this large integer format, and for someone that only needs 1s precision for their time (in a system where a large number of calculations on time are made), you wouldn't want to have the extra penalty of using high_precision_clock, when the system doesn't need it.

As to if there are such things in real life, I'm not sure. The key is that it's not a violation to the standard, if you care to implement it such.

Note that steady is very much a property of "what happens when the system changes time" (e.g. if the outside network has been down for a several days, and the internal clock in the system has drifted off from the atomic clock that the network time updates to). Using steady_clock will guarantee that time doesn't go backwards or suddenly jumps forward 25 seconds all of a sudden. Likewise, there is no problem when there is a "leap second" or similar time adjustment in the computer system. On the other hand, a system_clock is guaranteed to give you the correct new time if you give it a forward duration past a daylight savings time, or some such, where steady_clock will just tick along hour after hour, regardless. So choosing the right one of those will affect the recording of your favourite program in the digital TV recorder - steady_clock will record at the wrong time [my DTV recorder did this wrong a few years back, but they appear to have fixed it now].

system_clock should also take into account the user (or sysadmin) changing the clock in the system, steady_clock should NOT do so.

Again, high_resolution_clock may or may not be steady - it's up to the implementor of the C++ library to give the appropriate response to is_steady.

In the 4.9.2 version of <chrono>, we find this using high_resolution_clock = system_clock;, so in this case it's a direct typedef (by a different name). But the spec doesn't REQUIRE this.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • 1
    I had come to believe that `high_resolution_clock` was a mistake on my part. But I must admit that this is a pretty good argument to keep it. Though if I've got 128 bits to play with, I'm going for picoseconds not nanoseconds! :-) +1. – Howard Hinnant Feb 28 '16 at 16:34
  • Yeah, a picosecond clock would work for a few thousand years at 128 bits, wouldn't it... – Mats Petersson Feb 28 '16 at 16:38
  • @HowardHinnant This type of hypothetical thinking in order to squeeze out a reason behind something does not help me much with my question. In real life coding then, is it any good writing [this](http://stackoverflow.com/a/26141694/4224575) ? – Lorah Attkins Feb 28 '16 at 16:42
  • 2
    @LorahAttkins: I know of no implementation that implements `high_resolution_clock` as a separate type. Therefore I have been recommending that people utilize either `steady_clock` or `system_clock` (or their custom clock). `steady_clock` is best when you need a stop-watch. `system_clock` must be used if you need a time stamp with meaning across processes. – Howard Hinnant Feb 28 '16 at 16:53