是否存在 high_resolution_clock 不是 typedef 的标准库实现？

Question

C++ 草案 20.12.7.3 内容如下：

high_resolution_clock 可能是system_clock 或steady_clock 的同义词

当然，这可能没有任何要求，但我想知道：

• high_resolution_clock 对 typedef 以外的东西有什么意义吗？
• 有这样的实现吗？
• 如果设计了具有较短滴答周期的时钟，则它可以是稳定的，也可以是不稳定的。那么，如果存在这样的机制，我们难道不想“改进”system_clock 和high_resolution_clock，再次默认使用typedef 解决方案吗？

Answer 1

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

想象一个系统，其中时间通常以秒为单位，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 给出适当的响应。

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