普通、変数はバイト単位で扱います。ビット演算を行っても、結局変数はバイト単位で使わなければいけませんでした。今回は、本当にビット単位で変数を扱うことができる方法を話しましょう。
では、今回の要点です。
では、いってみましょう。
今回は西暦２０００年問題の謎を解いてみましょう。
西暦２０００年問題。それは１９９０年代末に世界を騒がせた問題です。それは、西暦を下２桁で扱っているプログラムが西暦２０００年を西暦１９００年と間違え、誤作動を起こしてしまう可能性がある、という問題でした。
年を扱うプログラムというのは多岐にわたり、様々なところでプログラムの修正、もしくは使用ソフトの変更などが行われてきました（多分）。その甲斐あってか、実際に問題の起きたケースは非常に少なく、平穏に時が流れていきました（多分）。（気象庁などで全く別の原因の閏年問題が起きましたが。）
西暦を下２桁で扱っていた理由は「データのサイズが減らせるから」でした。何百万、何千万といったデータを扱えば、１つ１つのデータ量を１バイト減らしただけでも１メガバイト、１０メガバイトとデータが減らせるわけです。今でこそハードディスクは数十ギガバイトが当たり前ですが、昔は記憶媒体のサイズも小さく、また、メモリのサイズも小さく、こういった努力は非常に重要でした（多分）。
しかし、ここで疑問が残ります。年月日を扱うときに、西暦を下２桁で扱うと本当にデータ量が減らせるのでしょうか？ 今回はそれを追求してみます。
先ず、年月日というデータはどのような量なのでしょうか？
年は、これといって範囲は決まっていません。しかし、コンピュータで扱う以上範囲は設定しなければいけません。とりあえず、西暦を生の値で保存したければ２バイトは必要となります。
次は月です。月は１〜１２まであり、１バイトの変数に入れられそうです。
次は日です。日は１〜３１まであり、これも１バイトの変数に入れられそうです。
ということで、年月日をまともに扱おうとすると４バイトの大きさになることが分かります。
ここで、年を下２桁で扱おうとするとどうなるでしょうか？ 下２桁となると範囲は０〜９９となり、１バイトにおさまります。ということで、合計３バイトとなり、節約になりました。
しかし、これでは無理に下２桁にしなくてもいいとは思いませんか？ ０〜２５５まで使えるのですから、せめて西暦２０９９年くらいまでは使えるようにしてくれていてもいいじゃないですか。
となると、まだデータ量を小さくする秘策がありそうです。もう少し、年月日というデータを突き詰めてみましょう。
先ず、月です。月は１〜１２まであります。よく考えてみると、このデータは０〜１５、つまり４ビットで表現できることが分かります。
次に、日です。日は１〜３１まであります。これもよく考えてみると、このデータは０〜３１、つまり５ビットで表現できることが分かります。
３バイトよりデータ量を少なくしようとすると、上の２つを足して１バイトと１ビットなのですから、最低でも２バイトは必要でしょう。ということで、残り７ビットに年を入れればいいわけです。
７ビットで表現できるデータは０〜１２７です。ということは０〜９９なら何とか入ります。ですが、それ以上は中途半端なのでこのあたりでうち切ろうと思います。
ということで、西暦を下２桁で扱えばデータは２バイトにおさまってしまうわけです。
この２バイトで収まってしまうところがあの騒ぎの原因になってしまった（多分）ことを考えると、いっそのこと収まらなかった方がよかったのではと思いたくなりますね。
さて、ビット演算でこれらのことを行おうとしてもかなり面倒です。Ｃ／Ｃ＋＋言語にはこれらのことを自動的にしてくれる便利な機能があります。それがビットフィールドです。
使い方は簡単です。構造体の宣言をするとき、メンバ変数名の後ろに : <ビット数> を書けばいいだけです。この変数のサイズはそこで指定されたビット数になります。
まぁ、とりあえず見てみましょう。
struct BDate
{
unsigned nYear : 7;
unsigned nMonth : 4;
unsigned nDay : 5;
};
このようにすれば、nYear の大きさは７ビット、nMonth の大きさは４ビット、nDay の大きさは５ビットになります。
ここで、型を見て下さい。ビット単位で変数を割り当てるのですが、その時型はどうなるのでしょうか？ サイズは自前で決めているのですから、あまり型には意味がないことが分かります。分かっていればいいのは符号付きか符号無しかだけですね。
ということで、ビットフィールドに使う変数の型は unsigned int, signed int, int に限定されています。ツールによっては制限をなくしているかもしれませんが、これが基本です。
unsigned int は unsigned と、signed int は signed と略せるので（これはビットフィールドに限ったことではありません）、unsigned か signed を使うと分かりやくてよいでしょう。int と signed int, signed は同じです。signed を int としても別に構わないでしょう。
これで、西暦２０００年問題は出ますが、年月日を２バイトで扱うことができました。
しかし、ビットフィールド全体のサイズは強制的に int と同じサイズ、もしくはその倍数にされてしまいます。昔は int のサイズが２バイトでしたのでこれでよかったのですが、今では４バイトになってしまってかえってサイズが増えてしまいますね。
そして、この年には実際は０〜１２７のデータが入ります。プログラムによっては西暦２０２８年問題が起きる可能性も...あるかもしれませんね。
そして、Ｗｉｎｄｏｗｓは西暦１９８０年からの経過年を使っています。ここでもそれプラス０〜９９年までということをやっています。つまり現在のＷｉｎｄｏｗｓは西暦２０８０年問題を抱えているということです。これがＷｉｎｄｏｗｓだけの話かどうかは知りませんが、まだまだ安心はできないかもしれませんね...と脅しておきましょう（ニヤリ）。
聞いた話によると、平成１０年にプログラムが誤作動するというプログラムもあったそうで、これはもう論外ですね。
最後は、ビットフィールドの色々な特徴について触れます。本当は２章に分ければいいのでしょうが、ビットフィールドに２章も割くつもりはないので。
先ず、ビットフィールドは構造体のメンバの一部であっても使えます。例えば、
struct BDate
{
unsigned nYear : 12;
unsigned nMonth : 4;
unsigned nDay : 5;
int nWeekday;
};
ということもできます。この場合、nYear から nDay までが int のサイズ、もしくはその倍数となります。つまり、３２ビット機であれば、この構造体の全体のサイズは８になります。
さらに、ビットフィールドはクラスと共用体でも使えます。
そして、ビットフィールドのアドレスは取得できません。アドレスはバイト単位の通し番号なので、当たり前ですね。
また、ビットを飛ばすこともできます。
struct BDate
{
unsigned nYear : 12;
unsigned nMonth : 4;
unsigned nDay : 5;
unsigned : 8;
unsigned nWeekday : 3;
};
名前を付けなければ、その部分は飛ばされます。名前なしの変数が作られていると思っても構いません。
また、int のサイズ以上のサイズを割り当てることはできません。
struct BDate
{
unsigned nYear : 33; // エラー
unsigned nMonth : 4;
unsigned nDay : 5;
};
そして、int のサイズの境界をまたぐことはできません。
struct BDate
{
unsigned nYear : 30;
unsigned nMonth : 4;
unsigned nDay : 30;
};
nYear のサイズは３０ビットです。int のサイズが３２とすると、あと２ビットしか残っていません。すると、nMonth はここに収まらないので、次の３２ビットの領域に割り当てられます。
そして、次の nDay は 残り２８ビットの領域に入らないので、さらに次の３２ビット領域に割り当てられます。
このせいで、一見８バイトに収まりそうなこの構造体のサイズは１２バイトになってしまいます。
最後に、強制的に次の int のサイズの境界に移すこともできます。
struct BDate
{
unsigned nYear : 12;
unsigned : 0;
unsigned nMonth : 4;
unsigned : 0;
unsigned nDay : 5;
};
名前のない、サイズ０のビットフィールドを作ろうとする感じですね。こうすると、ここで強制的に次の int のサイズの境界に移ることになります。
一見４バイトに収まりそうなこの構造体のサイズは、何と１２バイトになります。
駆け足でしたが、これらのことは何となく頭に入れておく程度でいいでしょう。ビットフィールドを実際に使おうとしたとき、ここを見返したのでいいでしょうね。
それでは、今回の要点です。最後に色々書きましたが、特に重要なのはこれくらいでしょうか。
次回は構造体を扱う上で注意しなければならない、とても重要なことをお話しします。同時に面白いマクロも紹介します。それでは。
Last update was done on 2000.8.7
この講座の著作権はロベールが保有しています