K.Maebashi's BBS

件名を変えました。 >># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション >># プログラムとしては、方向性が間違ってると思う。 … > 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? まあ、簡単に言ってしまえばそういうことです。 > でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 ファイルにデータを吐き出したいのなら結局バイト列まで面倒を見なければ いけないでしょう。int32_tを、32bitだからってそのままファイルに吐いてたら、 バイトオーダーの問題さえ解決できません。まあ、バイトオーダー(とか負の数の 表現方法とか)が同じ環境に限り移植性が高い、というだけでもメリットは もちろんあるので、全面的に否定はしませんが。 コンピュータの世界では、実に色々な概念が階層的に構成されていて、 ハードに近い「低レベルな」概念を、より抽象的な概念で隠す、という層の 積み重ねになっています。が、typedef int int32_t; は、より低レベルな階層を 剥き出しにする方向の定義になっている。これじゃあ向きが反対です。 その意味で、私は、Javaな人が、「Javaでは、Cなんかと違い、intとかの データ型のサイズがきちんと規定されているから良い」という主張が理解できません。 「intは最低限いくつからいくつまでの数を表現できる」という規定があれば (本来は)十分じゃないでしょうか。実際、Cの規格ではそれは保証していますし。 # intが3万ちょっとであふれるのは嫌だ、ということなら、「俺のプログラムは # intが32ビット以上の環境だけを対象とする」と言ってもよいでしょう。 2147483647に1足すと-2147483648になる、なんてことを仕様で保証しても、 「どの環境でも同じようにバグる」ことが保証できるだけでしょう。 現実問題としては「どの環境でも同じようにバグる」と助かるのは確かですが、 そういう意味で利便を図るなら、実行時エラーにする(できる)ほうが 筋が通ってますよね(C#のように)。 > 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 > 色々な環境からハードウエアを直に叩く様なアプリケーションを > 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 もちろんそういう低レベルな階層を意識しなければならないケースでは、 ビット数を意識する必要があると思います。それでもできるだけ階層化して、 下の方に押し込めたいところですが。