サイズ1の変数を作る

[徒歩]

サイズが1の変数の宣言として bool を使っていたのですが
インターネットでbool は処理系によってはサイズが違うと書かれていたので
自分で0と1だけの変数を宣言することは可能なのでしょうか？

[h2so5]

1bitの変数を宣言することはできません。
boolのサイズが処理系依存であることに何か不都合があるのでしょうか。

[みけCAT]

自分で0と1だけの変数を宣言することは可能なのでしょうか？

言語が指定されていませんが、C言語/C++ならenumを使うのはどうでしょうか？

コード:

enum ZeroOrOne {
	ZERO,ONE
};

ただし、これは「サイズ1の変数」という(私は理解していない)条件を満たさないかもしれません。

[徒歩]

＞boolのサイズが処理系依存であることに何か不都合があるのでしょうか。

場所によって製作環境が違うので対応させるとなると
何らかの方法でサイズを決める必要があると思いました。


＞言語が指定されていませんが、C言語/C++ならenumを使うのはどうでしょうか？

Ｃ言語です。　ゲームのフラグデータ保存用で使うのために配列が大きくなってしまいどうにか小さくしようと
思って質問しました

[みけCAT]

「サイズ1の変数」とはどういうことですか？
1バイトですか？1ワードですか？1セクタですか？1キロバイトですか？それとも…？

[徒歩]

フラグデータ用なので出来るだけ１ビットに近いもので出来るようにしたいです

[みけCAT]

unsigned char型ならパソコン向けのほとんどの環境では1バイト、8ビットだと思う[要出典]ので、
unsigned char型の変数にビット演算を利用してフラグを詰める、というのはどうでしょうか？

[h2so5]

具体的にどれくらいのデータサイズになるのでしょうか。
本当にビットを詰めなければならないほど余裕が無いのですか？

[みけCAT]

もしかして、PICなどのマイコンの開発でしょうか？

[徒歩]

＞unsigned char型の変数にビット演算を利用してフラグを詰める、というのはどうでしょうか？

ビット演算を利用してフラグを詰めることに
まったく気づきませんでした。ありがとうございます。

＞本当にビットを詰めなければならないほど余裕が無いのですか？

余裕が無いというほどではありませんが
フラグだけで1000個ほどになるので　サイズが小さくて読書きし易い形に出来ることが目標でした。

＞もしかして、PICなどのマイコンの開発でしょうか？

ＲＰＧゲームを作っています。

[h2so5]

ビットを詰めると逆に読み書きが難しくなります。
ファイルのサイズを小さくしたいのであればビットを詰めるのではなくgzipなどを利用したほうが良いと思います。

[ISLe]

ビットフィールドというものもあります。
環境依存が強いので外部記憶には向きませんが。

まあ、char配列の先頭から何ビット目を読み書きするという関数でも用意すれば済む話ですね。
マクロ等でどこを読み書きしてるか分かるようにすれば可読性もさほど悪くないですし。

[みけCAT]

＞本当にビットを詰めなければならないほど余裕が無いのですか？

余裕が無いというほどではありませんが
フラグだけで1000個ほどになるので　サイズが小さくて読書きし易い形に出来ることが目標でした。

＞もしかして、PICなどのマイコンの開発でしょうか？

ＲＰＧゲームを作っています。

マイコン開発を否定しませんでしたね。
自前でSDカードに書き込むときの実装をしやすくするため、データのサイズを1セクタに収めたい、ということでしょうか？

[softya（ソフト屋)]

パソコン前提なら1byte単位でON/OFF記録しても1000個x1byteでたかが1KB弱です。すごく小さなセーブデータだと思います。
たとえば、初代PSのメモリカードの１ブロックが8KBですから余裕で入るサイズですね。
このぐらいであれば、PSの開発者でもビットは使わないと思いますよ。

[ISLe]

フラグだけで1000個ほどになる、というのはフラグ以外にデータはないということになるのでしょうか。

[softya（ソフト屋)]

フラグだけで1000個ほどになる、というのはフラグ以外にデータはないということになるのでしょうか。

フラグ以外の容量がデカイのならそちらを問題にすべきかと思いますが、その場合でも1KB程度のフラグセーブデータは許容できるのではと思いました。
徒歩さんに言いたいのは、手間かけて容量を減らすよりも扱いやすくてデバッグしやすい方向でまとめた方が後々良いことばかりです。と言うことです。

[ISLe]

アクセス用の関数1つ挟むだけで済む話で、手間も掛からないのではないでしょうか。

配列に直接アクセスするよりも関数経由のほうが実装を隠蔽化できて拡張の幅が広がると思います。

わたしはロード・セーブでベタに読み書きするのは良くないと思うので、外部と内部の形式は切り離すべきと考えます。
1バイトずつでも1ビットずつでも自由に切り替えられるように作られているほうがデバッグもしやすいと思います。

[softya（ソフト屋)]

アクセスレベルの切り離す話と、セーブデータを1bitに押し込める話は別だと私は考えます。
もちろん、アクセスレベルはぜひ切り離すべきだと思っています。

ただ、1bitのデータの検証はバグった時にやはり面倒だと思う次第です。
少なくとも、実装レベルで１バイトづつセーブするよりコードが増えます。
わざわざ書かなくて良いコードを書いてるように思えてなりません。
必要ならすべきです。必要ないなら徹底して私は避けたいです。

[ISLe]

わたしは外部とやり取りするデータのサイズはユーザー体験に直結すると思っているので質問者さんの意向を尊重したいです。
これ以上はポリシーの問題なので議論は避けたいと思います。