By Cenoc


2010-07-23 13:12:58 8 Comments

I was wondering if someone could explain to me what the #pragma pack preprocessor statement does, and more importantly, why one would want to use it.

I checked out the MSDN page, which offered some insight, but I was hoping to hear more from people with experience. I've seen it in code before, though I can't seem to find where anymore.

10 comments

@Nick Meyer 2010-07-23 13:21:09

#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.

@jalf 2010-07-23 14:55:50

It might be worth adding the downsides of packing. (unaligned object accesses are slow in the best case, but will cause errors on some platforms.)

@user152949 2014-01-03 15:22:34

Seems the alignments "performance penalty" mentioned could actually be a benefit on some systems danluu.com/3c-conflict .

@Jacob Valenta 2014-04-04 15:01:42

What would #pragma pack(2) give you?

@Pacerier 2015-05-14 16:16:52

@jalf, Would Inge's link mean that packing is actually beneficial (as opposed to what you've written above)?

@jalf 2015-05-14 18:30:10

@Pacerier Not really. That post talks about some fairly extreme alignment (aligning on 4KB boundaries). The CPU expects certain minimum alignments for various data types, but those require, in the worst case, 8-byte alignment (not counting vector types which may require 16 or 32 byte alignment). Not aligning on those boundaries generally gives you a noticeable performance hit (because a load may have to be done as two operations instead of one), but the type is either well-aligned or it isn't. Stricter alignment than that buys you nothing (and ruins cache utilization

@jalf 2015-05-14 18:30:16

In other words, a double expects to be on an 8 byte boundary. Putting it on a 7 byte boundary will hurt performance. But putting it on a 16, 32, 64 or 4096 byte boundary buys you nothing above what the 8 byte boundary already gave you. You'll get the same performance from the CPU, while getting much worse cache utilization for the reasons outlined in that post.

@jalf 2015-05-14 18:32:03

So the lesson is not "packing is beneficial" (packing violates the types' natural alignment, so that hurts performance), but simply "don't over-align beyond what is required"

@Pacerier 2015-05-24 20:50:36

@IngeHenriksen, Do you agree with jalf's evaluation?

@Shocker 2017-07-03 14:22:50

Regarding what @jalf said about errors, here you can see an issue I encountered most likely due to pragma packs (I am not yet 100% sure though since, as explained, it's totally random, but pragma pack sounds like the culprit) stackoverflow.com/questions/30020759/…

@Marcin K. 2018-10-24 11:39:58

@jalf You mentioned that pragma pack might cause errors on some platforms. Would you be so kind to elaborate on this topic?

@Antti Haapala 2019-05-19 17:57:14

@MarcinK. Here's a crash on x86-64 with GCC. Similar is inevitable with any C compiler if they assume alignment and you pass a pointer to a packed member to a function.

@wangchow 2016-02-09 16:19:28

Note that there are other ways of achieving data consistency that #pragma pack offers (for instance some people use #pragma pack(1) for structures that should be sent across the network). For instance, see the following code and its subsequent output:

#include <stdio.h>

struct a {
    char one;
    char two[2];
    char eight[8];
    char four[4];
};

struct b { 
    char one;
    short two;
    long int eight;
    int four;
};

int main(int argc, char** argv) {
    struct a twoa[2] = {}; 
    struct b twob[2] = {}; 
    printf("sizeof(struct a): %i, sizeof(struct b): %i\n", sizeof(struct a), sizeof(struct b));
    printf("sizeof(twoa): %i, sizeof(twob): %i\n", sizeof(twoa), sizeof(twob));
}

The output is as follows: sizeof(struct a): 15, sizeof(struct b): 24 sizeof(twoa): 30, sizeof(twob): 48

Notice how the size of struct a is exactly what the byte count is, but struct b has padding added (see this for details on the padding). By doing this as opposed to the #pragma pack you can have control of converting the "wire format" into the appropriate types. For instance, "char two[2]" into a "short int" et cetera.

@xryl669 2016-09-13 15:39:42

No it's wrong. If you look at the position in memory of b.two, it's not one byte after b.one (the compiler can (and will often) align b.two so it's aligned to word access). For a.two, it's exactly one byte after a.one. If you need to access a.two as a short int, you should have 2 alternative, either use a union (but this usually fails if you have endianness issue), or unpack/convert by code (using the appropriate ntohX function)

@phuclv 2019-09-07 05:04:25

sizeof returns a size_t which must be printed out using %zu. Using the wrong format specifier invokes undefined behavior

@stonemetal 2010-07-23 13:26:35

I have seen people use it to make sure that a structure takes a whole cache line to prevent false sharing in a multithreaded context. If you are going to have a large number of objects that are going to be loosely packed by default it could save memory and improve cache performance to pack them tighter, though unaligned memory access will usually slow things down so there might be a downside.

@user23743 2010-07-23 13:25:16

I've used it in code before, though only to interface with legacy code. This was a Mac OS X Cocoa application that needed to load preference files from an earlier, Carbon version (which was itself backwards-compatible with the original M68k System 6.5 version...you get the idea). The preference files in the original version were a binary dump of a configuration structure, that used the #pragma pack(1) to avoid taking up extra space and saving junk (i.e. the padding bytes that would otherwise be in the structure).

The original authors of the code had also used #pragma pack(1) to store structures that were used as messages in inter-process communication. I think the reason here was to avoid the possibility of unknown or changed padding sizes, as the code sometimes looked at a specific portion of the message struct by counting a number of bytes in from the start (ewww).

@nmichaels 2010-07-23 13:24:53

#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.

@malhal 2014-01-12 20:14:54

To undo afterwards do this: #pragma pack(push,1) and #pragma pack(pop)

@Kirill V. Lyadvinsky 2010-07-23 13:24:30

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.

@Clifford 2010-07-23 13:22:25

A compiler may place structure members on particular byte boundaries for reasons of performance on a particular architecture. This may leave unused padding between members. Structure packing forces members to be contiguous.

This may be important for example if you require a structure to conform to a particular file or communications format where the data you need the data to be at specific positions within a sequence. However such usage does not deal with endian-ness issues, so although used, it may not be portable.

It may also to exactly overlay the internal register structure of some I/O device such as a UART or USB controller for example, in order that register access be through a structure rather than direct addresses.

@Pontus Gagge 2010-07-23 13:22:06

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.

@Tim Čas 2012-07-18 14:17:52

Actually, char a,b,c; will usually take either 3 or 4 bytes of storage (on x86 at least) -- that's because their alignment requirement is 1 byte. If it weren't, then how would you deal with char str[] = "foo";? Access to a char is always a simple fetch-shift-mask, while access to an int can be fetch-fetch-merge or just fetch, depending on whether it's aligned or not. int has (on x86) a 32-bit (4 byte) alignment because otherwise you'd get (say) half an int in one DWORD and half in the other, and that would take two lookups.

@Jerry Coffin 2010-07-23 13:21:07

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).

@Ashwin 2014-03-31 13:04:50

"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" - how would having 3 byte of padding maximize access speed?

@Jerry Coffin 2014-03-31 14:07:28

@Ashwin: Placing b at a 4-byte boundary means that the processor can load it by issuing a single 4-byte load. Although it depends somewhat on the processor, if it's at an odd boundary there's a good chance that loading it will require the processor to issue two separate load instructions, then use a shifter to put those pieces together. Typical penalty is on the order of 3x slower load of that item.

@SF. 2016-01-12 14:09:25

...if you look at the assembly code for reading aligned and unaligned int, aligned read is usually a single mnemonic. Unaligned read can be 10 lines of assembly easily as it pieces the int together, picking it byte by byte and placing at correct locations of the register.

@Jerry Coffin 2016-01-12 16:12:43

@SF.: It can be--but even when it's not, don't be misled--on an x86 CPU (for one obvious example) the operations are carried out in hardware, but you still get roughly the same set of operations and slowdown.

@msw 2010-07-23 13:20:34

You'd likely only want to use this if you were coding to some hardware (e.g. a memory mapped device) which had strict requirements for register ordering and alignment.

However, this looks like a pretty blunt tool to achieve that end. A better approach would be to code a mini-driver in assembler and give it a C calling interface rather than fumbling around with this pragma.

@Todd Lehman 2015-04-15 21:27:47

I actually use it quite a lot to save space in large tables which are not accessed frequently. There, it's only to save space and not for any strict alignment. (Just voted you up, btw. Someone had given you a negative vote.)

Related Questions

Sponsored Content

4 Answered Questions

[SOLVED] Why does pthread_cond_wait have spurious wakeups?

  • 2011-12-21 18:30:42
  • Jonathan M Davis
  • 27161 View
  • 134 Score
  • 4 Answer
  • Tags:   c pthreads

13 Answered Questions

[SOLVED] What is the effect of extern "C" in C++?

10 Answered Questions

[SOLVED] Improve INSERT-per-second performance of SQLite?

5 Answered Questions

[SOLVED] Is gcc's __attribute__((packed)) / #pragma pack unsafe?

  • 2011-12-19 22:28:00
  • Keith Thompson
  • 113061 View
  • 149 Score
  • 5 Answer
  • Tags:   c gcc pragma-pack

3 Answered Questions

[SOLVED] What is `#pragma pack` for in network programming?

  • 2011-06-15 04:36:01
  • codereviewanskquestions
  • 512 View
  • 1 Score
  • 3 Answer
  • Tags:   c++ pragma-pack

1 Answered Questions

[SOLVED] C++ #pragma pack

1 Answered Questions

[SOLVED] pragma pack(push) on iphone

3 Answered Questions

5 Answered Questions

[SOLVED] "Static const" vs "#define" for efficiency in C

0 Answered Questions

Variadic macro in Visual C++ 2010

Sponsored Content