アカウント名:
パスワード:
結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を 行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
「多い」と結論付ける資料も計算式も不明ですが。
結局はソースレビューするしか品質を維持できないと思ってます。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそのままで実装の微調整で逃げ始めるオチになることが多いでしょう。 time_t型にて時刻情報を常に取り扱い、 しかも計算途中で2倍するようなチョンボは設計そのものがおかしく、 実装は設計へ忠実に従ってるにすぎませんから、 その手のミスはソースレビューをしても合格扱いされることが多いものです。 上の段階の設計で大きな間違いをしているのに、 徹底的なソースレビューをすることで設計を忠実に実装していることを保証しても、 問題は解決しません。 それじゃ結局テスト至上主義と変わらない。
徹底的なソースレビューする余力があるなら それを削減して設計に対するレビューを増やした方が事故防止には有効。
ソースレビューできる実力のない人がリーダーやら上位設計をやっちゃダメってことです。
ソースの品質を向上させたり保証する能力と 設計に関する能力を一緒にしちゃダメってことです。
ソースの品質を向上させたり保証する能力と設計に関する能力を一緒にしちゃダメってことです。
まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
time_tをsigned __int64に変更するとしたら (スコア:1)
#ILP64な環境だとtime_tはどう定義されてるか興味津々
Re:time_tをsigned __int64に変更するとしたら (スコア:2, すばらしい洞察)
time_tそのものは32bitだと決まってるわけではないので
変更の必要性はありません。
ちゃんと作ってればソースへの変更は不要。
もっとちゃんと作ってればリコンパイルも不要。
数十年や数百年先、
さらには同じような扱いで数十年前や数百年前の時刻を
秒単位で管理するソフト作る場合は
始めからtime_tを利用せず代替ライブラリーを自分で用意するし。
結局のところ表現したい時刻の範囲と
それぞれの型によって表現可能な時刻の範囲の問題に関して
ちゃんと考えたことがあるのか、それともないのか
という点につきますよ
どういう理由で
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね?
まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
「多い」と結論付ける資料も計算式も不明ですが。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそのままで実装の微調整で逃げ始めるオチになることが多いでしょう。 time_t型にて時刻情報を常に取り扱い、 しかも計算途中で2倍するようなチョンボは設計そのものがおかしく、 実装は設計へ忠実に従ってるにすぎませんから、 その手のミスはソースレビューをしても合格扱いされることが多いものです。 上の段階の設計で大きな間違いをしているのに、 徹底的なソースレビューをすることで設計を忠実に実装していることを保証しても、 問題は解決しません。 それじゃ結局テスト至上主義と変わらない。
徹底的なソースレビューする余力があるなら それを削減して設計に対するレビューを増やした方が事故防止には有効。
ソースの品質を向上させたり保証する能力と 設計に関する能力を一緒にしちゃダメってことです。
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない
Re:time_tをsigned __int64に変更するとしたら (スコア:0)