標準自体によってsizeof（bool）が1に定義されていないのはなぜですか？
char、_signed char_、および_unsigned char_のサイズは、C++標準自体によって1バイトと定義されています。なぜsizeof(bool)も定義されなかったのだろうか？
C++ 03標準$ 5.3.3/1によると、
sizeof（char）、sizeof（signed char）、sizeof（unsigned char）は1です。 その他の基本型（3.9.1）に適用されたsizeofの結果は、実装によって定義されます。 [注：特に、sizeof（bool）とsizeof（wchar_t）は実装定義です。69）
sizeof（bool）は1バイト未満にすることはできません という理論的根拠を理解しています。しかし、それが1バイトより大きくなければならない理由はありますか？実装が1より大きいと定義していると言っているのではありませんが、標準では、1より大きい場合があるかのように実装によって定義されています。
sizeof(bool)が1より大きい理由がない場合、sizeof(char)を定義しているので、標準がそれを_1 byte_として定義しなかった理由がわかりません。そしてそれはすべての変種です。
多くのプラットフォームでは、32ビット未満の値を効果的にロードできません。 32ビットをロードし、シフトアンドマスク操作を使用して8ビットを抽出する必要があります。単一のboolsにはこれは必要ありませんが、文字列には問題ありません。
他の可能性のあるサイズはintのサイズであり、プラットフォームの「効率的な」整数型です。
実装が1を選択するかsizeof(int)を選択するかに違いが生じるアーキテクチャでは、サイズの間にトレードオフが生じる可能性があります（ただし、boolごとに7ビットを無駄にすることに満足している場合は、なぜすべきではありません） 31を無駄にしないでください？サイズが重要な場合はビットフィールドを使用してください）とパフォーマンス（ただし、bool値の格納と読み込みが真のパフォーマンスの問題になる場合は？速度が重要な場合は明示的にintを使用してください）。したがって、実装の柔軟性が優先されます-何らかの理由で1パフォーマンスやコードサイズの点でひどいものになるでしょう、それはそれを避けることができます。
@MSaltersが指摘したように、一部のプラットフォームは、より大きなデータ項目でより効率的に動作します。
多くの「RISC」CPU（MIPS、PowerPC、Alphaの初期バージョンなど）は、1ワード未満のデータを処理するのにかなり困難な時間を費やしていたため、同じことを行います。 IIRC、Alphaに少なくともいくつかのコンパイラがある場合、ブール値は実際には64ビットを占有していました。
powerPC Macのgccは、デフォルトでブール値に4バイトを使用していましたが、必要に応じて1バイトに変更するスイッチがありました。
X86の場合でも、32ビットのデータ項目を使用することにはいくつかの利点があります。 x86のgccには、BOOL_TYPE_SIZEの構成ファイルの1つに定義があります（または少なくとも以前はありませんでした）（メモリから取得するため、その名前を少し付けることができます）間違っている）1または4に設定してから、コンパイラを再コンパイルして、そのサイズのブール値を取得できます。
編集：この背後にある理由については、CとC++の基本的な哲学を単純に反映していると思います。実装がその動作を合理的に最適化/カスタマイズするための余地をできるだけ残してください。特定の動作を要求するのは、明白で具体的なメリットがあり、大きな責任が発生する可能性が低い場合、特に変更によって特定のプラットフォームでのC++のサポートが大幅に困難になる場合のみです（もちろん、プラットフォームが十分である場合）あいまいですが、無視される可能性があります）。
'sizeof'が生成された操作は、バイトではなくMADU（最小アドレス可能単位）です。したがって、ファミリプロセッサC54 *。 C55 * Texas Instuments、式1 MADU = 2バイト。
このプラットフォームの場合、sizeof（bool）= sizeof（char）= 1 MADU = 2バイト。これはC + +標準に違反していませんが、状況を明確にしています。