std::chrono::high_resolution_clock
| ヘッダー <chrono> で定義 |
||
| class high_resolution_clock; |
(C++11以降) | |
クラス std::chrono::high_resolution_clock は、実装が提供する最小のティック周期を持つクロックを表します。これは std::chrono::system_clock または std::chrono::steady_clock のエイリアスである場合もあれば、3番目の独立したクロックである場合もあります。
std::chrono::high_resolution_clock は TrivialClock の要件を満たします。
目次 |
[編集] メンバ型
| 型 | 定義 |
rep
|
クロックの期間におけるティック数を表す算術型 |
period
|
クロックのティック周期を秒単位で表す std::ratio 型 |
duration
|
std::chrono::duration<rep, period> |
time_point
|
std::chrono::time_point<std::chrono::high_resolution_clock> |
[編集] メンバ定数
| constexpr bool is_steady [static] |
ティック間の時間が常に一定である場合(つまり、now() への呼び出しが、何らかの外部クロック調整の場合でも単調に増加する値を返す場合)は true、そうでない場合は false (公開静的メンバ定数) |
[編集] メンバ関数
| [static] |
クロックの現在の値を表す std::chrono::time_point を返します。 (public static member function) |
[編集] 注記
high_resolution_clock の使用には、いくらかの論争がありました。この言語に high_resolution_clock を導入したと主張する Howard Hinnant は、2016 年に ISO C++ Standard - Discussion mailing list で、それを非推奨にすることを支持していると述べました。彼の根拠は、標準で std::chrono::steady_clock または std::chrono::system_clock のエイリアスになることが許可されているため、その使用はメリットなしにプログラムに不確実性を追加するということでした。しかし、スレッドの他の参加者は、std::chrono::steady_clock も std::chrono::system_clock も特定の分解能保証を伴わないため、high_resolution_clock は、ベンダーがプラットフォームの最高分解能クロックを提供する機会を与えることで有用な役割を果たし、どちらもそのクロックではないという点で、その支持を表明しました。
多くの場合、これは単に std::chrono::steady_clock または std::chrono::system_clock のエイリアスですが、どちらであるかはライブラリや設定によって異なります。system_clock の場合、単調ではありません(例:時間が逆行することがあります)。たとえば、2023 年現在、libstdc++ は「ナノ秒以上の定義が実現可能になるまで」system_clock のエイリアスとしています[1]。MSVC は steady_clock としています[2]。libc++ は、C++ 標準ライブラリ実装が単調クロックをサポートしている場合は steady_clock を使用し、それ以外の場合は system_clock を使用します[3]。
[編集] 関連項目
| (C++11) |
システム全体のリアルタイムクロックからの実時間 (クラス) |
| (C++11) |
調整されることのない単調増加クロック (クラス) |