なぜこの構造体のサイズが2ではなく3なのですか？

私はこの構造体を定義しました：

typedef struct
{
    char A:3;
    char B:3;
    char C:3;
    char D:3;
    char E:3;
} col; 

sizeof(col)私は3の出力を与えるが、それは2ではないでしょうか？1つの要素だけをコメント化するsizeofと、2になります。理由はわかりません。3ビットの5つの要素は15ビットに等しく、それは2バイト未満です。

このような構造を定義するときに「内部サイズ」はありますか？私の説明では、これまでの私の言語の概念から、サイズが3ではなく2バイトであると予想していたので、説明が必要です。

charフィールドの基本型として使用しているため、コンパイラはビットごとにビットをグループ化しようとします。各バイトに8ビットを超えることはできないため、バイトごとに2つのフィールドしか格納できません。

構造体が使用するビットの合計は15なので、多くのデータに適合する理想的なサイズはになりますshort。

#include <stdio.h>

typedef struct
{
  char A:3;
  char B:3;
  char C:3;
  char D:3;
  char E:3;
} col; 


typedef struct {
  short A:3;
  short B:3;
  short C:3;
  short D:3;
  short E:3;
} col2; 


int main(){

  printf("size of col: %lu\n", sizeof(col));
  printf("size of col2: %lu\n", sizeof(col2));

}

上記のコード（私のような64ビットプラットフォーム用）は、実際2に2番目の構造体の歩留まりになります。aよりも大きい場合short、構造体は使用されたタイプの要素を1つしか埋めないため、同じプラットフォームの場合、構造体のサイズはで4、intで8 longなどになります。

最小整列境界（1バイト）にまたがるビットパケットフィールドを持つことができないため、おそらく次のようにパックされます。

byte 1
  A : 3
  B : 3
  padding : 2
byte 2
  C : 3
  D : 3
  padding : 2
byte 3
  E : 3
  padding : 5

（同じバイト内のフィールド/パディングの順序は意図的ではありません。コンパイラーが好みに応じてそれらを配置できるため、それは単にアイデアを与えるためです）

最初の2つのビットフィールドは1つに収まりcharます。3番目はそれに適合できずchar、新しいものが必要です。3 + 3 + 3 = 9で、8ビット文字に収まりません。

したがって、最初のペアはを受け取りchar、2番目のペアはを受け取りchar、最後のビットフィールドは3番目を受け取りcharます。

ほとんどのコンパイラでは、たとえば#pragmas を使用して、パディングを制御できます。以下はGCC 4.8.1の例です。

#include <stdio.h>

typedef struct
{
    char A:3;
    char B:3;
    char C:3;
    char D:3;
    char E:3;
} col;

#pragma pack(push, 1)
typedef struct {
    char A:3;
    char B:3;
    char C:3;
    char D:3;
    char E:3;
} col2;
#pragma pack(pop)

int main(){
    printf("size of col: %lu\n", sizeof(col));  // 3
    printf("size of col2: %lu\n", sizeof(col2));  // 2
}

コンパイラーのデフォルトの動作は理由があるため、おそらくパフォーマンスが向上することに注意してください。

ANSI C規格では、ビットフィールドのパック方法の指定が少なすぎて、「コンパイラーはビットフィールドをパックできますが、適切と思われる」よりも優れていますが、それでも多くの場合、コンパイラーは最も効率的な方法で物をパックすることを禁止しています。

特に、構造体にビットフィールドが含まれている場合、コンパイラーは、「通常の」ストレージタイプの1つ以上の匿名フィールドを含む構造体として構造体を格納し、そのような各フィールドを構成するビットフィールド部分に論理的に分割する必要があります。したがって、与えられた：

unsigned char foo1: 3;
unsigned char foo2: 3;
unsigned char foo3: 3;
unsigned char foo4: 3;
unsigned char foo5: 3;
unsigned char foo6: 3;
unsigned char foo7: 3;

場合はunsigned char8ビットで、コンパイラは、そのタイプの四つのフィールドを割り当て、及び（にされるであろう全てが、1〜2ビットフィールドを割り当てるために必要とされるchar独自の分野）。すべてのchar宣言がに置き換えられた場合short、タイプの2つのフィールドがありshort、1つは5つのビットフィールドを保持し、もう1つは残りの2つを保持します。

アラインメント制限のないプロセッサunsigned shortでは、最初の5つのフィールドに使用unsigned charし、最後の2つのフィールドに7つの3ビットフィールドを3バイトで格納することにより、データをより効率的にレイアウトできます。3つのバイトに8つの3ビットフィールドを格納することは可能ですが、コンパイラは、「外部フィールド」タイプとして使用できる3バイトの数値タイプが存在する場合にのみ許可できます。

個人的には、ビットフィールドは基本的に役に立たないと定義されていると考えています。コードがバイナリでパックされたデータを処理する必要がある場合は、実際の型の格納場所を明示的に定義し、マクロまたはその他の手段を使用してそのビットにアクセスする必要があります。Cが次のような構文をサポートしていると便利です。

unsigned short f1;
unsigned char f2;
union foo1 = f1:0.3;
union foo2 = f1:3.3;
union foo3 = f1:6.3;
union foo4 = f1:9.3;
union foo5 = f1:12.3;
union foo6 = f2:0.3;
union foo7 = f2:3.3;

このような構文が許可されている場合は、コードがビットサイズを移植可能な方法で使用できるようになります。ワードサイズやバイト順は関係ありません（foo0はf1の最下位3ビットにありますが、これらは下位または上位のアドレス）。ただし、そのような機能がない場合、マクロはおそらくそのようなものを操作する唯一の移植可能な方法です。