C language structure alignment

From: http://blog.csdn.net/wze2009/article/details/5456106

C-language structure alignment is also a common topic. This is basically a mandatory question for the interview questions. Although the content is very basic, it will be wrong if you are not careful. Write a struct and then sizeof. Do you often feel strange about the results? The result of sizeof is usually larger than the total length of the variable you declare. What is the problem?

At the beginning, I was also troubled by such problems for a long time. In fact, there are a lot of related articles, and I feel that there are not many clear articles. How is the structure aligned?

Some people have summarized the alignment principle. I can't remember where I can see it now. Here I will reference previous experiences (without the # pragma pack macro ):

Principle 1. Data member alignment rules: data members of a structure (struct or union), where the first data member is placed at 0 in offset, in the future, the starting position of each data member storage starts from an integer multiple of the member size (for example, if the int value is 4 bytes on a 32-bit host, it starts from an integer multiple of 4 ).

Principle 2: struct as a member: If a structure contains some struct members, the struct members should be stored from an integer multiple of the internal maximum element size. (Struct a contains struct B, B contains char, int, double and other elements, and B should be stored as an integer multiple of 8 .)

Principle 3. Final work: the total size of the struct, that is, the result of sizeof, must be an integer multiple of the largest member in the structure, and the deficiencies must be completed.

How can we understand these three principles? Let's take a look at the following examples to deepen our understanding through examples.

Example 1: struct {
Short A1;
Short A2;
Short A3;
};

Struct {
Long A1;
Short A2;
} B;

Sizeof (A) = 6; it is easy to understand that all three short are 2.

Sizeof (B) = 8; is this two bytes larger than expected? Long is 4, short is 2, and the whole is 8, because principle 3.

Example 2: struct {
Int;
Char B;
Short C;
};

Struct B {
Char B;
Int;
Short C;
};

Sizeof (A) = 8; int is 4, char is 1, short is 2, here we use principles 1 and 3.

Sizeof (B) = 12; is it beyond the expected range? Char is 1, Int Is 4, and short is 2. Why is it 12? Or principles 1 and 3.

Let's take a closer look at the memory layout.

A B C
Memory layout of A: 1111, 1 *, 11

B A C
Memory layout of B: 1 ***, 1111, 11 **

The asterisk (*) indicates the padding byte. In A, why does B need to add A byte? Because c is short, its starting position must be a multiple of 2, that is, principle 1. C is not supplemented, because B and c occupy exactly four bytes, and the space occupied by A is A multiple of 4, that is, the maximum Member of the int type, so do not add.

In B, B is char 1, and B is followed by three bytes. Because a is an int of 4, according to principle 1, the starting position must be a multiple of 4, therefore, B must be followed by three bytes. C is followed by two bytes. According to principle 3, the space occupied by B is a multiple of 4. c is not followed, and the space occupied by B is 10, therefore, we need to add two bytes.

Let's look at an example with structure members in the structure:

Example 3: struct {
Int;
Double B;
Float C;
};

Struct B {
Char E [2];
Int F;
Double G;
Short h;
Struct a I;
};

Sizeof (A) = 24; it is better to understand that int is 4, double is 8, float is 4, and the total length is a multiple of 8, so the entire A is 24.

Sizeof (B) = 48; check the memory layout of B.

E F G H I

B's memory layout: 11 **, 1111,111 11111, 11 *******, 1111 *****, 11111111,111 1 ****

I is actually the memory layout of. The starting position of I must be a multiple of 24, so h must be completed. The memory layout of B is clear, and the alignment of the struct is basically mastered.

None of the above is the # pragma pack macro. If there is a # pragma pack macro, the alignment is defined according to the macro. For example, if # pragma pack (1) is added before the above struct, the memory layout will change completely. Sizeof (A) = 16; sizeof (B) = 32;

With the # pragma pack (1), the memory will no longer follow principles 1 and 3 and is aligned by 1 byte. That's right. Isn't that an ideal world without memory alignment.

A B C
A memory layout: 1111,111 11111, 1111

E f g h I

B memory layout: 11,111 1, 11111111, 11,111 1, 11111111,111 1

So # What is the result of pragma pack (2? # What about pragma pack (4? Let's leave it for everyone to think. I believe there is no problem.

There is also a common case where the struct contains bitfield fields. Bit Field members cannot be taken sizeof value separately. C99 specifies that int, unsigned int, and bool can be used as bit domain types, but almost all compilers have extended these types to allow the existence of other types.

The main purpose of bit domains is to compress storage. The general rules are as follows:
1) if the types of adjacent fields are the same, and the sum of the bit widths is smaller than the sizeof size of the type, the subsequent fields will be stored next to the previous field until they cannot be accommodated;
2) If the Field Types of adjacent bit fields are the same, but the sum of Bit Width is greater than the sizeof size of the type, the subsequent fields start from the new storage unit, its offset is an integer multiple of its type;
3) if the types of adjacent bit field are different, the implementations of each compiler are different. VC6 adopts the non-compression mode and Dev-C ++ adopts the compression mode;
4) do not compress fields that are interspersed with non-bit fields;
5) the total size of the entire struct is an integer multiple of the size of the widest basic type.

Let's take a look at the example.

Example 4: struct {
Char F1: 3;
Char F2: 4;
Char F3: 5;
};

A B C
Memory layout of A: 111,111 1 *, 11111 ***

The bit field type is Char, and the 1st bytes can only accommodate F1 and F2, so F2 is compressed to 1st bytes, while F3 can only start from the next byte. Therefore, the result of sizeof (a) is 2.

Example 5: struct B {
Char F1: 3;
Short F2: 4;
Char F3: 5;
};

Because the adjacent bit fields have different types, in vc6, sizeof is 6, and in Dev-C ++ is 2.

Example 6: struct C {
Char f1: 3;
Char f2;
Char f3: 5;
};

The non-bit field is interspersed in it and will not produce compression. The size obtained in VC6 and Dev-C ++ is 3.

Consider one question: why do we need to design a memory alignment processing method? If the architecture is not aligned, the members will be stored one by one, obviously alignment is a waste of space. So why use alignment? Alignment and non-alignment of the architecture are a trade-off between time and space. Alignment saves time. Assuming that the length of an architecture is W, it also assumes that in this architecture, the most frequent processing of data with a width of W is also the most important. It is designed to give priority to improving the efficiency of W-bit data operations. If you are interested, You can Google it. People can explain a lot of truth to you.

By the way, when designing a struct, we generally consider the habit of placing the types that occupy a small amount of space at the top, and those that occupy a large amount of space at the bottom, in this way, alignment space is saved.