4

パケットがあるとします

struct Foo
{
    short size; // 2
    short type; // 2
    BYTE  data; // 1
    //1 byte padding not 3?
};

コンパイル後は、構造体の最後に 1 バイトのパディングが追加された 6 バイトの長さになります。構造体のサイズが 8 バイトになるように、コンパイラは 3 バイトのパディングを追加することになっていませんか? 32 ビットの CPU は 4 バイトのチャンクでデータにアクセスするのが好きなので

ところで、 #pragma pack(1) を使用すると、予想どおり 5 バイトの長さになります。

4

3 に答える 3

8

あなたには s がstruct含まれていますshort。これは、2 バイト境界で整列する必要がある可能性が高いことを意味します。この構造体の配列をパディングなしで作成すると、他のすべての要素の short が正しく整列されず、クラッシュしたり遅くなったりする可能性があります。

パディングは、安全性とパフォーマンスを目的として存在します。特定のアーキテクチャでは、位置合わせされていない読み取りによってクラッシュが発生します。そのため、コンパイラは構造体をパディングして、メンバーがサイズで割り切れるアドレスに整列するようにします。それとは別に、コンパイラは、構造体全体をネイティブの単語境界に揃えるためだけに余分なパディングを追加する理由はほとんどありません。したがって、あなたの場合は1バイトだけ追加されます。

構造体に an を入れてみてくださいint。これにより、パディングが変更され、さらに 3 バイトのパディングが追加されます。また、 2 バイトの間にあると、バイト間intにパディングが作成されます。

コンパイラは、明示的にパッキングを指定しない限り、パディングに関して自由に選択できます。異なるアーキテクチャや異なるコンパイラでは、異なることが起こります。

于 2012-08-29T17:58:58.267 に答える
4

既に 1 バイトと 2 バイトの増分でメモリにアクセスしているstructため、構造体を 6 バイトと 8 バイトに揃えることでパフォーマンスがさらに低下することはなく、コンパイラはスペースを節約することを選択します。構造体のアラインメントについて仮定をせず、コンパイラに正しいことをさせれば、実際には心配する必要はありません。

于 2012-08-29T18:00:24.657 に答える
2

32 ビットの CPU は 4 バイトのチャンクでデータにアクセスするのが好きなので

ではない正確に。厳密に言えば、アクセスする変数の長さがバイト長で、変数アドレスが-bytes でアラインされている場合、メモリ アクセスはアラインされます (ここではアラインメントについて話しているため) 。 したがって、4 バイトでアラインされているという意味ではありません。型を宣言し、データ範囲が 2 バイトである 場合のように、2 バイトに揃えることができます。NN
short

于 2012-08-29T18:03:52.517 に答える