#pragma pack effect
#pragma pack
instructs the compiler to pack structure members with particular alignment. Most compilers, when you declare a struct, will insert padding between members to ensure that they are aligned to appropriate addresses in memory (usually a multiple of the type's size). This avoids the performance penalty (or outright error) on some architectures associated with accessing variables that are not aligned properly. For example, given 4-byte integers and the following struct:
struct Test
{
char AA;
int BB;
char CC;
};
The compiler could choose to lay the struct out in memory like this:
| 1 | 2 | 3 | 4 |
| AA(1) | pad.................. |
| BB(1) | BB(2) | BB(3) | BB(4) |
| CC(1) | pad.................. |
and sizeof(Test)
would be 4 × 3 = 12, even though it only contains 6 bytes of data. The most common use case for the #pragma
(to my knowledge) is when working with hardware devices where you need to ensure that the compiler does not insert padding into the data and each member follows the previous one. With #pragma pack(1)
, the struct above would be laid out like this:
| 1 |
| AA(1) |
| BB(1) |
| BB(2) |
| BB(3) |
| BB(4) |
| CC(1) |
And sizeof(Test)
would be 1 × 6 = 6.
With #pragma pack(2)
, the struct above would be laid out like this:
| 1 | 2 |
| AA(1) | pad.. |
| BB(1) | BB(2) |
| BB(3) | BB(4) |
| CC(1) | pad.. |
And sizeof(Test)
would be 2 × 4 = 8.
Order of variables in struct is also important. With variables ordered like following:
struct Test
{
char AA;
char CC;
int BB;
};
and with #pragma pack(2)
, the struct would be laid out like this:
| 1 | 2 |
| AA(1) | CC(1) |
| BB(1) | BB(2) |
| BB(3) | BB(4) |
and sizeOf(Test)
would be 3 × 2 = 6.
#pragma
is used to send non-portable (as in this compiler only) messages to the compiler. Things like disabling certain warnings and packing structs are common reasons. Disabling specific warnings is particularly useful if you compile with the warnings as errors flag turned on.
#pragma pack
specifically is used to indicate that the struct being packed should not have its members aligned. It's useful when you have a memory mapped interface to a piece of hardware and need to be able to control exactly where the different struct members point. It is notably not a good speed optimization, since most machines are much faster at dealing with aligned data.
To undo afterwards wrap in #pragma pack(push,1)
and #pragma pack(pop)
It tells the compiler the boundary to align objects in a structure to. For example, if I have something like:
struct foo {
char a;
int b;
};
With a typical 32-bit machine, you'd normally "want" to have 3 bytes of padding between a
and b
so that b
will land at a 4-byte boundary to maximize its access speed (and that's what will typically happen by default).
If, however, you have to match an externally defined structure you want to ensure the compiler lays out your structure exactly according to that external definition. In this case, you can give the compiler a #pragma pack(1)
to tell it not to insert any padding between members -- if the definition of the structure includes padding between members, you insert it explicitly (e.g., typically with members named unusedN
or ignoreN
, or something on that order).
Data elements (e.g. members of classes and structs) are typically aligned on WORD or DWORD boundaries for current generation processors in order to improve access times. Retrieving a DWORD at an address which isn't divisible by 4 requires at least one extra CPU cycle on a 32 bit processor. So, if you have e.g. three char members char a, b, c;
, they actually tend to take 6 or 12 bytes of storage.
#pragma
allows you to override this to achieve more efficient space usage, at the expense of access speed, or for consistency of stored data between different compiler targets. I had a lot of fun with this transitioning from 16 bit to 32 bit code; I expect porting to 64 bit code will cause the same kinds of headaches for some code.
Compiler could align members in structures to achieve maximum performance on the certain platform. #pragma pack
directive allows you to control that alignment. Usually you should leave it by default for optimum performance. If you need to pass a structure to the remote machine you generally will use #pragma pack 1
to exclude any unwanted alignment.