问具有直接QueryPerformanceCounter值的时钟是否符合C++标准？

EN

它不会完全兼容标准的时钟要求。但大多数情况下，它会编译并执行您想做的事情。不符合的部分是，您必须为您的period指定time_point所基于的内容。某些东西不一定与物理时间单位相对应。

这并不重要，除非减去两个time_points，得到一个duration，然后将这个duration与表示物理时间的东西进行比较。然后你会得到运行时间的垃圾。

另外，如果您在time_point中使用这样的sleep_until或wait_until，那么您的程序就不会休眠或等待预定的时间。

下面是一个基于QueryPerformanceCounter的计时时钟示例，它使用QueryPerformanceFrequency：https://stackoverflow.com/a/15755865/576911确定物理单元

按照Hinnant的解释，重新定义的time_point和duration与编译时已知的period不对应的时钟不符合Clock要求。

使用模拟算术类型的类来隐藏其他实现细节不起作用。

由于Standard没有定义这个仿真是什么，所以只有标准实现提供的时钟才有机会使用仿真类型。作为一个实际的证明，std::chrono和boost::chrono在boost::rational中不能很好地工作。

但是，一般的任务是避免对每次查询进行分割，至少有两种实用的解决方案。

第一种解决方案是遵循将分割延迟到需要时的意图，而不是重新定义time_point和duration。定义符合标准的时钟，作为扩展，定义原始时间戳的接口。所以，时钟可以有raw_now()方法，返回raw_time_point类型，这样的区别是raw_duration类型。raw_time_point可以隐式转换为time_point，raw_duration可转换为duration。

第二种解决方案是为每次查询计算符合标准的time_point，但是使用不需要除法操作的分水岭库执行快速除法。

库接受除数并对其进行处理，以便使用已处理除数的每个分区都使用快速操作完成。当然，处理除数需要时间，但是对于使用相同除数的重复除法，它是一次性开销。因此，这个库看起来是这个任务的理想匹配。(请注意，对于编译时已知的常量，库并不有用，因为在本例中，编译器避免了自己的除法，但是QueryPerformanceFrequency结果是运行时常量)。