アカウント名:
パスワード:
あたりまえだけど、開発環境が64ビット化した時にバイナリデータがずれて難儀した。言語仕様で最初からビット幅固定してくれればよかったのにとか思ってしまった。
その時代,時代で"普通のデータ幅"って変わりますからねえ。int16_tみたいに数値の入った型名でないかぎり、変化するのはしかたがないかと。それより、ビットフィールドの詰め方が規定されていないのが残念でならない。ただどっちから詰めてもいいというだけではなく、どっちから詰めるようにしているかを知る手段すらも規定されていないとは。そのせいで、bit毎に意味付けされているハードウェアのportを叩くときにビットフィールドが使えないんです。今時はメモリ節約なんてメリットよりサイクル数の増大というデメリットのほうが大きいことが多いから、日の目をみることはほとんどないですが、詰め方が規定されていればI/O portの記述に適していたはず。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
shortは16ビットじゃないしlongは32ビットじゃない (スコア:0)
あたりまえだけど、開発環境が64ビット化した時にバイナリデータがずれて難儀した。
言語仕様で最初からビット幅固定してくれればよかったのにとか思ってしまった。
Re:shortは16ビットじゃないしlongは32ビットじゃない (スコア:0)
その時代,時代で"普通のデータ幅"って変わりますからねえ。int16_tみたいに数値の入った型名でないかぎり、変化するのはしかたがないかと。
それより、ビットフィールドの詰め方が規定されていないのが残念でならない。ただどっちから詰めてもいいというだけではなく、どっちから詰めるようにしているかを知る手段すらも規定されていないとは。
そのせいで、bit毎に意味付けされているハードウェアのportを叩くときにビットフィールドが使えないんです。
今時はメモリ節約なんてメリットよりサイクル数の増大というデメリットのほうが大きいことが多いから、日の目をみることはほとんどないですが、詰め方が規定されていればI/O portの記述に適していたはず。