编译器可以对结构中的成员进行对齐，以在特定平台上实现最大性能。#pragma包指令允许你控制对齐方式。通常，您应该将其保留为默认值以获得最佳性能。如果你需要传递一个结构到远程机器，你通常会使用#pragma pack 1来排除任何不需要的对齐。

数据元素(例如类和结构的成员)通常在当前一代处理器的WORD或DWORD边界上对齐，以提高访问时间。在32位处理器上，在不能被4整除的地址处检索DWORD至少需要一个额外的CPU周期。如果你有三个char成员char a b c;，它们实际上会占用6到12个字节的存储空间。

#pragma允许你覆盖这个，以实现更有效的空间使用，以访问速度为代价，或为了不同编译器目标之间存储的数据的一致性。从16位代码到32位代码的转换给我带来了很多乐趣;我预计移植到64位代码也会对某些代码造成同样的困扰。

你可能只在对某些硬件(例如内存映射设备)编码时才会使用它，这些硬件对寄存器排序和对齐有严格的要求。

然而，这似乎是实现这一目标的一个相当生硬的工具。一个更好的方法是在汇编程序中编写一个迷你驱动程序，并给它一个C调用接口，而不是摸索这个pragma。

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

代码的原始作者还使用#pragma pack(1)来存储在进程间通信中用作消息的结构。我认为这里的原因是为了避免未知或更改填充大小的可能性，因为代码有时会通过从开始计算字节数来查看消息结构的特定部分(ewww)。

编译器可以对结构中的成员进行对齐，以在特定平台上实现最大性能。#pragma包指令允许你控制对齐方式。通常，您应该将其保留为默认值以获得最佳性能。如果你需要传递一个结构到远程机器，你通常会使用#pragma pack 1来排除任何不需要的对齐。

我见过有人使用它来确保一个结构占用整个缓存行，以防止在多线程上下文中错误共享。如果你将有大量的对象，在默认情况下将它们松散地打包，它可以节省内存并提高缓存性能，尽管未对齐的内存访问通常会降低速度，所以可能会有一个缺点。