是否存在标准库实现，其中high_resolution_clock不是typedef？

Question

C ++草案par 20.12.7.3 读取：

  

high_resolution_clock可能是system_clock或steady_clock

的同义词

当然，可能强制要求，但我不知道：

• high_resolution_clock对于typedef的其他内容是否有任何意义？
• 有这样的实现吗？
• 如果设计一个具有较短滴答周期的时钟，它可以是稳定的或不稳定的。因此，如果存在这样的机制，我们是否也不想“改进”system_clock和high_resolution_clock，再次默认为typedef解决方案？

Answer 1

规范有措辞的原因如＆＃34;可能＆＃34;和＆＃34; can＆＃34;以及允许其他可能性的其他含糊不清的词来自规范编写者不希望（不必要地）限制＆＃34;更好＆＃34;的实现的愿望。某事的解决方案。

想象一个系统，其中一般的时间以秒为单位计算，而system_clock就是那个 - system_clock::period将返回1秒。此时间存储为单个64位整数。

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

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

请注意，稳定非常属于＆＃34;当系统改变时间时会发生什么？ （例如，如果外部网络已经关闭了几天，并且系统中的内部时钟已从网络时间更新的原子钟中消失）。使用steady_clock将保证时间不会倒退或突然间突然向前跳跃25秒。同样，当有一个＆＃34;闰秒时，没有问题。或类似的计算机系统时间调整。另一方面，system_clock保证为您提供正确的新时间，如果您给它一个超过夏令时的前进持续时间，或某些此类，steady_clock将在一小时一小时内打勾， 而不管。因此，选择正确的一个将影响您在数字电视录像机中录制您最喜爱的节目 - steady_clock将在错误的时间录制[我的DTV录像机几年前做错了，但它们似乎已修复它现在]。

system_clock还应考虑用户（或系统管理员）更改系统中的时钟，steady_clock不应该这样做。

同样，high_resolution_clock可能是也可能不是steady - 它可以由C ++库的实现者提供给is_steady的适当响应。

在<chrono>的4.9.2版本中，我们找到了此using high_resolution_clock = system_clock;，因此在这种情况下，它是直接typedef（使用不同的名称）。但规范并不需要这个。