是否有标准库实现，其中high_resolution_clock不是 typedef

Is there a standard library implementation where high_resolution_clock is not a typedef?

本文关键字：resolution clock 不是 typedef high 其中标准实现是否更新时间：2023-10-16

C++草案第20.12.7.3段如下：

high_resolution_clock可能是system_clock或steady_clock的同义词

当然，这可能什么都不要求，但我想知道：

high_resolution_clock到其他的东西有什么意义吗？
有这样的实现吗？
如果设计了一个时钟周期较短的时钟，它可以是稳定的，也可以是不稳定的。因此，如果存在这样的机制，我们是否也想"改进"system_clock和high_resolution_clock，再次默认为typedef解决方案？

规范具有诸如"可以"和"可以"之类的措辞以及其他允许其他可能性的模糊词的原因来自规范编写者不希望（不必要地）限制某些"更好"解决方案的实现的愿望。

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

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

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

请注意，稳定在很大程度上是"当系统改变时间时会发生什么"的属性（例如，如果外部网络已经关闭了几天，并且系统中的内部时钟已经偏离了网络时间更新到的原子钟）。使用steady_clock可以保证时间不会倒退或突然向前跳跃 25 秒。同样，当计算机系统中存在"闰秒"或类似的时间调整时，也没有问题。另一方面，如果您给system_clock一个超过夏令时的正向持续时间，或者类似的时间，那么肯定会给你正确的新时间，无论如何，steady_clock都会一小时又一小时地滴答作响。因此，选择其中正确的一个会影响您在数字电视录像机中录制您喜欢的节目 - steady_clock会在错误的时间录制[我的 DTV 录像机几年前做错了，但他们现在似乎已经修复了它]。

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

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

在 4.9.2 版本的 <chrono> ，我们发现这个 using high_resolution_clock = system_clock; ，所以在这种情况下它是一个直接typedef（名称不同）。但是规范不需要这个。