在打印我的日志时，我希望每条消息都有一个时间戳，用于测量自程序启动以来的时间。最好以纳秒为单位，但毫秒也可以:
( 110 ns) Some log line
( 1220 ns) Another log line
( 2431 ns) Now for some computation...
(10357 ns) Error!
对于上述任务，每个任务的优缺点是什么？
最佳答案
system_clock 是一个与 UTC 保持时间的时钟(不包括闰秒)。每隔一段时间(可能一天几次)，它会进行少量调整，以使其与正确的时间保持一致。这通常是通过网络服务(如 NTP)完成的。这些调整通常以微秒为单位，但可以在时间上向前或向后。这个时钟的时间戳实际上有可能(虽然不太可能也不常见)倒退一小部分。除非被管理员滥用，system_clock由于夏令时或更改计算机的本地时区，因此不会按总量跳跃，因为它始终跟踪 UTC。
steady_clock 就像一个秒表。它与任何时间标准都没有关系。它只是不断滴答作响。它可能不会保持完美的时间(真的没有时钟)。但它永远不会被调整，尤其是不会向后调整。它非常适合对短代码进行计时。但由于它从未得到调整，它可能会随着时间的推移而漂移 system_clock调整为与 UTC 保持同步。
这归结为事实steady_clock最适合短时间的计时。它还通常具有纳秒分辨率，尽管这不是必需的。和 system_clock最适合计时“长”时间，其中“长”非常模糊。但当然小时或天有资格被称为“长”，而一秒以下的持续时间则不然。如果您需要将时间戳与人类可读的时间(例如民用日历上的日期/时间)相关联，system_clock是唯一的选择。
high_resolution_clock 允许是 steady_clock 的类型别名或 system_clock ，而且在实践中总是如此。但有些平台别名为 steady_clock还有一些到 system_clock .所以恕我直言，最好直接选择steady_clock或 system_clock这样你就知道你得到了什么。
虽然没有指定， std::time 通常仅限于一秒的分辨率。因此，对于需要亚秒级精度的情况，它完全无法使用。否则 std::time跟踪UTC(不包括闰秒)，就像system_clock .
std::clock 跟踪处理器时间，而不是物理时间。也就是说，当您的线程不忙于做某事并且操作系统已将其停放时，测量值 std::clock不会反射(reflect)在停机期间增加的时间。如果这是您需要测量的内容，这可能非常有用。如果您使用它而没有意识到您正在测量处理器时间，这可能会非常令人惊讶。
和 C++20 的新功能
C++20 为 <chrono> 增加了四个时钟图书馆:
utc_clock 就像 system_clock ，除了它计算闰秒。这主要在您需要减去两个 time_point 时有用。 s 跨越闰秒插入点，您绝对需要计算插入的闰秒(或其一部分)。
tai_clock 测量自 1958-01-01 00:00:00 以来的秒数，并在该日期比 UTC 提前 10 秒。它没有闰秒，但每次在 UTC 中插入闰秒时，TAI 和 UTC 的日历表示法就会相差一秒。
gps_clock 模拟 GPS 时间系统。它测量自 1980 年 1 月第一个星期日 00:00:00 UTC 以来的秒数。与 TAI 一样，每次在 UTC 中插入闰秒时，GPS 和 UTC 的日历表示法又会偏离一秒。由于 GPS 和 TAI 处理 UTC 闰秒的方式相似，因此 GPS 的日历表示始终比 TAI 的日历表示晚 19 秒。
file_clock 是 filesystem 使用的时钟库，并且是产生 chrono::time_point 的原因别名 std::filesystem::file_time_type .
可以使用 C++20 中名为 clock_cast 的新命名强制转换。在 time_point 之间转换system_clock的s , utc_clock , tai_clock , gps_clock和 file_clock .例如:
auto tp = clock_cast<system_clock>(last_write_time("some_path/some_file.xxx"));
tp的类型是 system_clock基于 time_point同 duration类型(精度)为 file_time_type .
关于c++ - 用于记录时间戳的不同 C++ 时钟的优缺点是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/64080301/