C++草案参数20.12.7.3内容如下:
high_resolution_clock可能是system_clock或的同义词steady_clock
当然,这可能只是强制要求,但我想知道:
high_resolution_clocktypedef的其他东西有什么意义吗？system_clock,high_resolution_clock并且typedef再次违反解决方案？规范之所以有诸如“可能”和“可以”之类的措辞，以及其他允许其他可能性的模糊词语，是因为规范编写者不想（不必要地）限制某些“更好”解决方案的实现。
想象一下一个系统，其中时间通常以秒为单位计算，并且就是system_clock这样 -system_clock::period将返回 1 秒。该时间存储为单个 64 位整数。
现在，在同一个系统中，也有一个以纳秒为单位的时间，但它存储为 128 位整数。由于这种大整数格式，结果时间计算稍微复杂一些，对于只需要 1 秒精度的时间的人（在进行大量时间计算的系统中），您不希望有high_precision_clock当系统不需要它时使用 的额外惩罚。
至于现实生活中是否有这样的事情，我不确定。关键是，如果您愿意这样实施的话，这并不违反标准。
请注意，稳定很大程度上是“系统改变时间时会发生什么”的属性（例如，如果外部网络已经关闭几天，并且系统中的内部时钟已经偏离网络时间的原子钟）更新至）。使用steady_clock将保证时间不会突然倒退或突然向前跳25秒。同样，当计算机系统中存在“闰秒”或类似的时间调整时，也没有问题。另一方面，system_clock如果您给它一个超过夏令时或类似的时间的向前持续时间，则保证为您提供正确的新时间，无论如何，它steady_clock只会一小时又一小时地滴答作响。因此，选择正确的其中一个将影响数字电视录像机中您最喜欢的节目的录制 -steady_clock将在错误的时间进行录制[我的数字电视录像机几年前就犯了这个错误，但他们现在似乎已经修复了它]。
system_clock还应该考虑用户（或系统管理员）更改系统中的时钟，steady_clock不应该这样做。
再说一次，high_resolution_clock可能是也可能不是steady——这取决于 C++ 库的实现者对is_steady.
在 4.9.2 版本中<chrono>，我们找到了 this using high_resolution_clock = system_clock;，因此在本例中它是直接的typedef（使用不同的名称）。但规范并不要求这样做。