アカウント名:
パスワード:
結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を 行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
「多い」と結論付ける資料も計算式も不明ですが。
結局はソースレビューするしか品質を維持できないと思ってます。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ
ソースの品質を向上させたり保証する能力と設計に関する能力を一緒にしちゃダメってことです。
結局はソースレベルで具体的に指示できるだけの実力がない人が設計したりリーダをやっちゃうと、ヌケヌケのシステムになっちゃうし、いつまでたってもそれを改善できなくて、まともなモノにならないということですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
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)
「多い」と結論付ける資料も計算式も不明ですが。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
結局はソースレベルで具体的に指示できるだけの実力がない人が設計したりリーダをやっちゃうと、ヌケヌケのシステムになっちゃうし、いつまでたってもそれを改善できなくて、まともなモノにならないということですね。
Re:time_tをsigned __int64に変更するとしたら (スコア:0)