在許多廣泛應用的程序庫，我們會看到類似 #pragma pack(push, 4) 等這樣的標示。因為用戶會任意更改他們的結構成員對齊選項，對于先于這些內容創建的程序庫來說，不能確保一定的內存布局將可能在預先書寫的一些數據訪問模塊上導致錯誤，或者根本不可能實現。
我在實現一種 C++ 類的實例的序列化工具時，依賴了內存布局。我知道市面上很多“序列化”工具允許更為廣泛的通信用途，但是它們也是用起來最麻煩的，有很多限制條件。我實現的序列化工具用意很明顯，為特定運行模塊提供便捷高效的持久化存儲能力。
為了提供感性的認識，提供了一個使用這個序列化工具的類型定義。
class StorageDoc
: public SerialOwner
{
public:
Serializable(StorageDoc);
char c;
int i;
SerialString str;
};
它繼承自 SerialOwner，它聲明了 Serializable，隱含著實現了一些接口，為基類訪問當前類型信息提供幫助。這是較早書寫的一種方案，現在我會改用模板以便在編譯時建立類型信息，不過原理完全一樣。
現在，StorageDoc 當中的內存布局需要可確定的，但是用戶會選擇不同的結構成員對齊選項，為此需要設定一個結構成員對齊的“子域”，完成這項能力的偽指令是 #pragma pack。
#pragma pack( [ show ] | [ push | pop ] [, identifier ] , n )
1）當選用 show，則添加一條警告信息，指示當前編譯域內的對齊屬性
2）僅僅設置 n，則重寫編譯器選項 /Zp，并影響到此聲明以下的同一個編譯單元內的所有結構定義
3）push 以及 pop 管理了一組“子域”堆棧，可以不斷加深嵌套
4）identifier 命名了堆棧上的對齊項，以便在特定需求中彈出合適的項目
以下是使用的注意事項：
1）不論何時，#pragma pack() 總是恢復到 /Zp 的預設值，即使處于 push 的“子域”
2）#pragma pack(push) 未指定對齊值，則不改變
3）#pragma pack(pop) 可指定對齊值出棧后的設置值，若不指定則按嵌套等級還原，直至 /Zp 預設值
綜上，#pragma pack(pop) 總是能正確回退到上一個作用域，不管該作用域通過 #pragma pack(n) 聲明或者 #pragma pack(push, n)。而 #pragma pack() 總是取預設值。對于用戶事先指定了一個“子域”，并在其中引入了一個使用 #pragma pack(n) - #pragma pack() 對而非堆棧形式來聲明局部結構成員對齊的頭文件，會使用戶非常困惑。 就是這樣做的。
當我們為程序庫編譯運行時，有一些類型要求嚴格地遵守內存布局，比如一些硬件允許我們傳入的數據就需要這么做，就可以把它們限定起來：
#pragma pack(push, 8)
#include "Chain.h"
#include "ByteQueue.h"
#include "SerialOwner.h"
#include "SerialUser.h"
#include "SerialString.h"
#include "SerialStream.h"
#pragma pack(pop)
事情再回到序列化上面，用戶會多次嘗試編譯他們的序列化應用模塊，并指望前一次編譯之后運行所產生的文件仍然是可用的，所以還需要在用戶文件當中明確所選用的對齊值，并一旦確定就不再更改：
#pragma pack(push, 8)
class StorageDoc
: public SerialOwner
{
public:
Serializable(StorageDoc);
char c;
int i;
SerialString str;
};
#pragma pack(pop)
并使用它們：
StorageDoc doc;
doc.Load(t("doc.bin"));
std::cout << doc.str.Get() << std::endl;
doc.str = ss.str();
std::cout << doc.str.Get() << std::endl;
doc.Save(t("doc.bin"));
這就是全部了，但是正如以上提到的，不僅僅在序列化上，和硬件、鏈接庫的通信也可能存在嚴格的內存布局的要求，如果你在項目設計上遭遇這些困惑，那么現在就可以立即動手解決它們。
如果對本文提到的序列化能力感興趣的話，可以到以下鏈接了解詳情：
http://code.google.com/p/los-lib/source/browse/
目錄是：
svn/trunk/Inc/Los/
文件分別是：
_ISerialUser.h
ByteQueue.h
Chain.h
Serialization.h
SerialOwner.h
SerialStream.h
SerialString.h
SerialUser.h
不過在本文發布之時，以上文件所處版本沒有針對結構成員對齊選項進行修改，但并不影響閱讀。
* 補充一（2009-1-18 02:41）
聯合以及結構的結構成員對齊異常
class Tick
{
static int _StaticID;
__int64 _StartLI; // __alignof(LARGE_INTEGER) != __alignof(__int64)
__int64 _CurrentLI;
__int64 _Frequency;
int _ID;
clock_t _Start;
clock_t _Current;
bool _Stop;
bool _HighPerformance;
...
}
LARGE_INTEGER 是分別對應兩個 32bit 以及一個 64bit 類型的聯合，奇怪的是隨著全局對齊選項的修改，LARGE_INTEGER 類型本身的請求對齊 __alignof(LARGE_INTEGER) 將取聯合的成員的最大者同全局對齊選項的最小值，也就是說，當 /Zp 設置為 2，那么 LARGE_INTEGER 也將僅承諾在 2 字節邊界上對齊，多么不幸啊。當然如果將這個類型納入 #pragma pack 的限定域那就什么問題都沒有了，不管聯合的對齊算法多么的古怪，只要保證不修改所需的對齊值那將總是能獲得確定的內存布局。
不過正如上面的代碼列出的，我使用了 __int64 代替了 LARGE_INTEGER 的工作，并在請求 Win32 API 的接口上強制指針轉型，使用的時候亦如此，但若訪問聯合成員剛好為 __int64 類型則直接使用便可。這種方式沒有獲得額外的好處，算是一種抗議的行為，并且讓后來的閱讀者有機會了解到這個見不得光的問題。
_HighPerformance = ::QueryPerformanceFrequency((LARGE_INTEGER*)&_Frequency) != 0;
當然作為嚴肅的代碼寫作者，也許你將在不止一處使用到 LARGE_INTEGER，為此我也不拒絕使用如下格式：
#pragma pack(push, 8)
#include
#pragma pack(pop)
它可保證你萬無一失。
作為對比，FILETIME 有如下定義：
typedef struct _FILETIME
{
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME;
且不論它所需的可能的最大結構成員對齊為 4，它也將伴隨著 /Zp 的更改而變動。因此，在不同的選項的影響下：
__alignof(LARGE_INTEGER) != __alignof(FILETIME) != __alignof(__int64)
有些人可能要指責會發生這樣的問題純粹是用戶在玩弄“結構成員對齊選項”而導致的，我真希望他能夠讀一讀這篇文章。
* 補充二（2009-1-18 02:41）
D3D 與用戶定義結構的協調
class VertexXYZ_N_T1
{
public:
float x, y, z;
float normal_x, normal_y, normal_z;
float u, v;
DeviceBitmap* bitmap;
Material* material;
float temp_val;
static const int FVF = D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1;
};
這是一個自定義頂點結構，它的最大成員字節數為 4，所有的成員也都是 4 字節邊界，不論作何選項，始終保持緊湊存儲，若其中一個成員擴展為 8 字節，那么伴隨著選項的更改，VertexXYZ_N_T1 要求的對齊邊界可導致部分空洞，從而同硬件所需的頂點緩存數據布局存在出入，我不追究硬件是否使用 double 值，但是現在就應當使用
#pragma pack(push, 4)
...
#pragma pack(pop)
加以限定。
我還定義了 Matrix, Material, Vector3, Colorf 等類型，如果要使得這些數據同 D3D, D3DX 的相應類型在內存上兼容的，也是需要限定的。