c – 是否存在标准库实现,其中high_resolution_clock不是typedef？

C草案20.12.7.3内容如下：

high_resolution_clock may be a synonym for system_clock or steady_clock

当然这可能只是强制要求,但我想知道：

>对于highderesolution_clock,还有其他类型的typedef吗？
>有这样的实现吗？
>如果设计一个具有较短滴答周期的时钟,它可以是稳定的或不稳定的.因此,如果存在这样的机制,我们是否也不想“改进”system_clock和high_resolution_clock,再次默认为typedef解决方案？

解决方法

规范具有诸如“可能”和“可以”之类的措辞,以及允许其他可能性的其他模糊词语的原因来自规范编写者不希望(不必要地)限制某种“更好”解决方案的实现的愿望. .

想象一个系统,其中一般的时间以秒为单位计算,而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(用不同的名字).但规范并不要求这样做.