想象一个系统,其中一般的时间以秒为单位计算,而system_clock就是这样 – system_clock :: period将返回1秒.此时间存储为单个64位整数.

现在,在同一系统中,还有一个以纳秒为单位的时间,但它存储为128位整数.由于这种大整数格式,所得到的时间计算稍微复杂一些,并且对于那些只需要1s精度的人来说(在系统中按时进行大量计算),你不希望有当系统不需要时,使用high_precision_clock的额外惩罚.

至于现实生活中是否有这样的事情,我不确定.关键是,如果你愿意实施它,它不违反标准.

请注意,稳定性是“当系统更改时间时会发生什么”的一个属性(例如,如果外部网络已经关闭了几天,并且系统中的内部时钟已经从网络时间的原子钟中消失了更新).使用steady_clock将保证时间不会倒退或突然突然向前跳跃25秒.同样,当计算机系统中存在“闰秒”或类似的时间调整时,没有问题.另一方面,如果你给予夏令时超过夏令时的前进持续时间,系统时钟可以保证给你正确的新时间,或者一些这样的时间,无论如何,steady_clock只是一小时一小时地打勾.因此,选择正确的一个将影响您在数字电视录像机中录制您喜欢的节目 – steady_clock将在错误的时间录制[我的DTV录像机几年前就做错了,但它们现在似乎已修复它].

system_clock还应考虑用户(或sysadmin)更改系统中的时钟,steady_clock不应该这样做.

同样,high_resolution_clock可能稳定也可能不稳定 – 这取决于C库的实现者对is_steady给出适当的响应.

在< chrono>的4.9.2版本中,我们使用high_resolution_clock = system_clock;来找到它,所以在这种情况下它是一个直接的typedef(用不同的名字).但规范并不要求这样做.