Sizeof (struct)

Sizeof is an operator that can be used for any variable name, type name, or constant value. It does not need parentheses when used for variable names (not array names) or constants.

It works during compilation rather than runtime.
This is the most frequently asked question for beginners, so it is necessary to pay more attention here. Let's first look at a struct:
Struct S1
{
Char C;
Int I;
};
Ask how smart the sizeof (S1) is. You start to think about it. Char occupies 1 byte and INT occupies 4 byte. Then, the total value should be 5. Is that true? Have you tried it on your machine? Maybe you are right, but you are probably wrong! In vc6, the default value is 8.
Why is my injury always me?
Don't be frustrated. Let's take a look at the definition of sizeof. The result of sizeof is equal to the number of memory bytes occupied by the object or type. Well, let's take a look at the memory allocation of S1:
S1 S1 = {'A', 0 xffffffff };
After defining the above variables, add breakpoints, run the program, and observe the memory where S1 is located. what do you find?
Take my vc6.0 as an example. The S1 address is 0x0012ff78, and its data content is as follows:
0012ff78: 61 CC FF
What are the three-byte CC in the middle? Let's take a look at the description on msdn:
When applied to a structure type or variable, sizeof returns the actual size, which may include Padding Bytes inserted for alignment.
Originally, this is the legendary byte alignment! An important topic has emerged.
Why do we need byte alignment principles to teach us how to speed up the computer's data acquisition speed? Otherwise, it will take a longer command cycle. For this reason, the compiler will process the struct by default (in fact, the data variables in other places are also the same), so that the basic data type with a width of 2 (short, etc) are located on the address that can be divisible by 2, so that the basic data type (INT, etc.) with the width of 4 is located on the address that can be divisible by 4, and so on. In this way, the two numbers may need to be added to the padding byte, so the sizeof value of the entire struct increases.
Let's exchange the positions of char and INT in S1:
Struct S2
{
Int I;
Char C;
};
Let's look at the number of sizeof (S2) results. How can we still look at the memory at 8? The original member C still has three Padding Bytes. Why? Don't worry. The following summarizes the rules.
The details of byte alignment are related to compiler implementation, but generally three criteria are met:
1) The first address of the struct variable can be divisible by the size of its widest basic type member;
2) The offset (offset) of each member of the struct to the first address of the struct is an integer multiple of the member size. If necessary, the compiler will add the internal adding between the members );
3) the total size of the struct is an integer multiple of the size of the widest basic type of the struct. If necessary, the compiler will add the trailing padding after the last member ).
There are several notes for the above principles:
1) I didn't mean that the address of a struct member is an integer multiple of its size. How can I talk about the offset? Because a 1st point exists, we can only consider the member offset, this is easy to think about. Think about why.
The offset of a member of the struct to the first address of the struct can be obtained through the macro offsetof (). This macro is also defined in stddef. H, as follows:
# Define offsetof (S, m) (size_t) & (S *) 0)-> m)
For example, to get the offset of C in S2, the method is
Size_t Pos = offsetof (S2, c); // POS equals 4
2) The basic type refers to the built-in data types such as char, short, Int, float, and double. The "data width" here refers to the size and size of sizeof. Because the struct member can be a composite type, for example, another struct, when looking for the widest basic type member, it should include the Child Member of the composite type member, instead of seeing a composite member as an integer. However, when determining the offset of a composite member, the composite type is regarded as a whole.
This is a bit difficult to describe here, and it seems a bit confusing to think about it. Let's take a look at the example (the specific value is still taken as an example of vc6 and will not be explained later ):
Struct S3
{
Char C1;
S1 S;
Char C2;
};
The type of the widest and simplest member of S1 is int. When considering the widest and simplest type members, S3 splits S1, so the widest and simplest type of S3 is int. In this way, for variables defined by S3, the first address of the bucket needs to be divisible by four, and the entire sizeof (S3) value should also be divisible by four.
The offset of C1 is 0, and the offset of S is a whole. As a struct variable, S satisfies the preceding three criteria, so its size is 8, the offset is 4 (I understand it as sizeof (S1), and the pointer is 4). Three bytes are required between C1 and S, and no need between C2 and S, therefore, the offset of C2 is 12, and the size of C2 is 13, and 13 cannot be fully divided by 4. In this way, three filling bytes must be added at the end. Finally, the value of sizeof (S3) is 16.
Through the above description, we can get a formula:
The size of the struct is equal to the offset of the last member plus the size of the struct plus the number of filled bytes at the end, that is:
Sizeof (struct) = offsetof (last item) + sizeof (trailing padding)
Here, friends should have a new understanding of the sizeof struct, but don't be too happy. An important parameter that affects sizeof has not been mentioned yet, that is the pack instruction of the compiler. It is used to adjust the structure alignment mode. Different compiler names and usages are slightly different. In vc6, the # pragma pack is used for implementation, and you can also directly modify the/ZP compilation switch. # Basic usage of The Pragma Pack: # pragma pack (N), where N is the number of bytes alignment. The default value is 8, if this value is smaller than the sizeof value of the struct
The offset of the member should take this value as the standard, that is, the offset of the struct member should take the minimum value of the two,
The formula is as follows:
Offsetof (item) = min (n, sizeof (item ))
Let's look at the example:
# Pragma pack (push) // Save the current pack setting pressure Stack
# Pragma pack (2) // must be used before struct Definition
Struct S1
{
Char C;
Int I;
};
Struct S3
{
Char C1;
S1 S;
Char C2;
};
# Pragma pack (POP) // restore previous pack settings
When sizeof (S1) is calculated, the value of min (2, sizeof (I) is 2, so the offset of I is 2, and the value of sizeof (I) is 6, it can be divisible by 2, so the size of the entire S1 is 6.
Similarly, for sizeof (S3), the offset of S is 2, the offset of C2 is 8, and the addition of sizeof (C2) is equal to 9, cannot be divisible by 2, add a fill byte, so sizeof (S3) is equal to 10.
Now, friends can breathe a sigh of relief ,:)
Note that the size of the "Empty struct" (excluding data members) is not 0, but 1. Imagine how a variable with "no space occupied" can be separated by an address and two different "Empty struct" variables. Therefore, the variable "Empty struct" must also be stored, in this way, the compiler can only allocate one byte of space for occupying space. As follows:
Struct S5 {};
Sizeof (S5); // The result is 1.

Sizeof containing bitfield struct:
As mentioned above, bitfield members cannot be individually sizeof values. Here we will discuss the sizeof of struct containing the bitfield, but specifically list it in consideration of its particularity.
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 type of the adjacent bit field is the same and the sum of its bit width is smaller than the sizeof size of the type
Segments are stored next to the previous field until they cannot be accommodated;
2) If the field type of the adjacent bit field is the same, but the sum of its bit width is greater than the sizeof size of the type
The offset from the new storage unit is an integer multiple of its type;
3) if the types of adjacent bitfield fields are different, the implementations of each compiler are different.
Type, Dev-C ++ adopts the compression method;
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 1:
Struct bf1
{
Char F1: 3;
Char F2: 4;
Char F3: 5;
};
Its memory layout is:
|__ F1 ___ | ____ F2 ___ |__ | ____ F3 ______ |
|__ |
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 only
Starting from the next byte. Therefore, the result of sizeof (bf1) is 2.
Example 2:
Struct bf2
{
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 3:
Struct bf3
{
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.