Q&A
ご回答ありがとうございます。
サイズ的に問題ないのは承知していたのですが、内部の処理も問題ないでしょうか？問題ないように作ると思いますが、確信がないので念のため…
PCの時刻変更については、steady_clockだと時刻に影響を受けないので確認することが出来ません。（実動作は確認していないので後で確認してみます）
C++のstd::chrono::steady_clockを使用して経過時間の差分を計測したいと考えているのですが、chronoで2038年問題のような「bit幅が不十分な整数型の利用によって生じる問題」は発生しうるでしょうか？（質問がわかりにくかったためyohhoyさんの表現をお借りしました）
問題になるような実装はしないと思うのですが、裏付ける物を見つけられなかったため質問しました。
組み込みシステムでの利用を考えており、詳細は以下の通りです。
- CPU: Arm(32bit)
- OS: Linux(Yocto) カーネル3.2以降
- コンパイラ: gccのC++14に対応している物
回答2件
0
ベストアンサー
C++のstd::chrono::steady_clockを使用して経過時間の差分を計測したいと考えているのですが、chronoは2038年問題に対応しているのでしょうか？（2038年問題の時刻をまたぐ際に正常に計算できるか）
C++標準ライブラリのstd::chrono::steady_clockは、基点(epoch)を特に定めない「時間逆行しない時計(clock)」としか定義されません。（外部サーバとの時刻同期操作などの要因によって、通常の“システム時計”はプログラムからみて時間逆行する可能性があります。）
2038年問題 は「UNIX epoch(1970-01-01T00:00:00Z)からの経過時間を32bit幅符号付き整数型で表現 するケースで生じうる問題」を指します。UNIX epochと異なる基点をもつ時計においては、狭義の2038年問題とは無関係です。
C++標準ライブラリではstd::chrono::system_clockや、C++20で追加されるutc_clockがUNIX epochと同じ基点を持ちます。
2038年問題を「bit幅が不十分な整数型の利用によって生じる問題」と広く解釈した場合、厳密にはC++標準ライブラリの実装品質(Quality of Implementation)依存となります。とはいえ、2038年問題が認識されてから実装されたライブラリにおいて、そのような低品質な実装が存在するとは考えにくいでしょう。
投稿2020/11/06 04:45
編集2020/11/06 04:53
総合スコア6191
0
おそらく可能です
std::chrono::steady_clockの返却する型time_pointの最大サイズは、以下で確認できます
これはWikipeに西暦3000億年まで保存できるサイズとして紹介されています
不安であれば、
PCの時間を2038年になるようにして確認すればよいと思います
投稿2020/11/04 05:05
総合スコア44
ドキュメントには、
steady_clockのエポックは未規定だが、多くの実装ではプログラム起動時間が時間ゼロのエポックとして定義され、その時間からの時間間隔がカウントされる。とされています
https://cpprefjp.github.io/reference/chrono/steady_clock.html
つまり、UNIX時間の開始時刻の代わりにプログラムの開始時刻を開始時刻として、そこからの経過秒数をカウントします
そのカウントされている時間が
2,147,483,647秒を超えるとエラーになるかという話だとすると、
返却されている型のサイズ的には可能ですが、
確認する手段はわからないです(エポックの初期値を弄れれば可能)
実時間の2038年がカウントに影響あるかは
PCの時間をずらして動作させ、動くのであれば問題ないと思います
ご回答ありがとうございます。
エポック初期値の変更を検討してみたいと思います。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/11/06 05:23
2020/11/06 07:08 編集
2020/11/06 07:22 編集
2020/11/09 04:50