アカウント名:
パスワード:
あたりまえだけど、開発環境が64ビット化した時にバイナリデータがずれて難儀した。言語仕様で最初からビット幅固定してくれればよかったのにとか思ってしまった。
16bitの変数が使いたければ int16_t を、32bitの変数が使いたければ int32_t を使いましょう。C99で規格化されています。
メインフレームとかであった24ビットマシンとか36ビットマシンとかでも使えるのかね?・そういう環境ではint16_t等を未定義にすることが許されている・そういう環境ではC99を満たすコンパイラを作れない・そういう環境ではビットマスクとかで無理やり実現しているさあどれだ?
答えは1つめですね。
int16_t などは「処理系定義」(implementation-defined)です。int16_t がなくてもC99として問題ありませんが、int16_t が定義されている処理系では、int16_tは「そのサイズがピッタリ16bitであること」「負数の表現方法は2の補数であること」が保証されます。(素の int は、負数の表現方法も規定されていません。まあ大抵は2の補数ですけど、例えば「符号ビットと絶対値」みたいな内部表現の処理系も許されます。)
あとは、変な処理系向けの型としては、「int_least16_t」(16bit以上で最小の型)や「int_fast16_t」(16bit以上で処理系最速の型)もあります。こっちは必須。
その時代,時代で"普通のデータ幅"って変わりますからねえ。int16_tみたいに数値の入った型名でないかぎり、変化するのはしかたがないかと。それより、ビットフィールドの詰め方が規定されていないのが残念でならない。ただどっちから詰めてもいいというだけではなく、どっちから詰めるようにしているかを知る手段すらも規定されていないとは。そのせいで、bit毎に意味付けされているハードウェアのportを叩くときにビットフィールドが使えないんです。今時はメモリ節約なんてメリットよりサイクル数の増大というデメリットのほうが大きいことが多いから、日の目をみることはほとんどないですが、詰め方が規定されていればI/O portの記述に適していたはず。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
shortは16ビットじゃないしlongは32ビットじゃない (スコア:0)
あたりまえだけど、開発環境が64ビット化した時にバイナリデータがずれて難儀した。
言語仕様で最初からビット幅固定してくれればよかったのにとか思ってしまった。
Re:shortは16ビットじゃないしlongは32ビットじゃない (スコア:1)
16bitの変数が使いたければ int16_t を、
32bitの変数が使いたければ int32_t を使いましょう。
C99で規格化されています。
Re: (スコア:0)
メインフレームとかであった24ビットマシンとか36ビットマシンとかでも使えるのかね?
・そういう環境ではint16_t等を未定義にすることが許されている
・そういう環境ではC99を満たすコンパイラを作れない
・そういう環境ではビットマスクとかで無理やり実現している
さあどれだ?
Re:shortは16ビットじゃないしlongは32ビットじゃない (スコア:1)
答えは1つめですね。
int16_t などは「処理系定義」(implementation-defined)です。int16_t がなくてもC99として問題ありませんが、int16_t が定義されている処理系では、int16_tは「そのサイズがピッタリ16bitであること」「負数の表現方法は2の補数であること」が保証されます。(素の int は、負数の表現方法も規定されていません。まあ大抵は2の補数ですけど、例えば「符号ビットと絶対値」みたいな内部表現の処理系も許されます。)
あとは、変な処理系向けの型としては、「int_least16_t」(16bit以上で最小の型)や「int_fast16_t」(16bit以上で処理系最速の型)もあります。こっちは必須。
Re: (スコア:0)
その時代,時代で"普通のデータ幅"って変わりますからねえ。int16_tみたいに数値の入った型名でないかぎり、変化するのはしかたがないかと。
それより、ビットフィールドの詰め方が規定されていないのが残念でならない。ただどっちから詰めてもいいというだけではなく、どっちから詰めるようにしているかを知る手段すらも規定されていないとは。
そのせいで、bit毎に意味付けされているハードウェアのportを叩くときにビットフィールドが使えないんです。
今時はメモリ節約なんてメリットよりサイクル数の増大というデメリットのほうが大きいことが多いから、日の目をみることはほとんどないですが、詰め方が規定されていればI/O portの記述に適していたはず。