>803
フラグ管理のときに


あくまで my事例だけどさ
最近インテルコンパイラを試してて、描画高速化の為にビット意識してソース書きなおしたり 部分をアセンブラにしたり。
そーいう分野では過去のローテクもある程度活躍してる。
でも フラグ管理の処理が遅くて or フラグの数がもの凄くて ビットに圧縮しないと 動きません ってのには遭遇したことが無い。

メインゲームループで秒間60回も呼ばれるようなフラグ管理なら 設計が悪い。
10000個のフラグがあるならフラグの数を減らす事を考える。

後はコードの可読性とのバランスじゃないかな。

まぁ即興ではっつけたソースコードに突っ込みいれるのも情けが足りないとは思うけど
n>>3とか 配列のインデックスに使うなんて俺には考え欄内し、マジックナンバーが多すぎる。
例え 定数化したりマクロ化したりして意味のある ラベルを付けたとしても
それは フラグと仮定したら「複数の意味の異なる値に依存する単一の値」で
数値と仮定したら「サイズ上限がタイトに決まった値」な訳で、設計変更や仕様変更に弱すぎる。

と、俺は思う。