在許多廣泛應用的程序庫，我們會看到類似 #pragma pack(push, 4) 等這樣的標示。因為用戶會任意更改他們的結構成員對齊選項，對于先于這些內容創(chuàng)建的程序庫來說，不能確保一定的內存布局將可能在預先書寫的一些數(shù)據(jù)訪問模塊上導致錯誤，或者根本不可能實現(xiàn)。
我在實現(xiàn)一種 C++ 類的實例的序列化工具時，依賴了內存布局。我知道市面上很多“序列化”工具允許更為廣泛的通信用途，但是它們也是用起來最麻煩的，有很多限制條件。我實現(xiàn)的序列化工具用意很明顯，為特定運行模塊提供便捷高效的持久化存儲能力。
為了提供感性的認識，提供了一個使用這個序列化工具的類型定義。
class StorageDoc
: public SerialOwner
{
public:
Serializable(StorageDoc);
char c;
int i;
SerialString str;
};
它繼承自 SerialOwner，它聲明了 Serializable，隱含著實現(xiàn)了一些接口，為基類訪問當前類型信息提供幫助。這是較早書寫的一種方案，現(xiàn)在我會改用模板以便在編譯時建立類型信息，不過原理完全一樣。
現(xiàn)在，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() 對而非堆棧形式來聲明局部結構成員對齊的頭文件，會使用戶非常困惑。 就是這樣做的。
當我們?yōu)槌绦驇炀幾g運行時，有一些類型要求嚴格地遵守內存布局，比如一些硬件允許我們傳入的數(shù)據(jù)就需要這么做，就可以把它們限定起來：
#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)
事情再回到序列化上面，用戶會多次嘗試編譯他們的序列化應用模塊，并指望前一次編譯之后運行所產(chǎn)生的文件仍然是可用的，所以還需要在用戶文件當中明確所選用的對齊值，并一旦確定就不再更改：
#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"));
這就是全部了，但是正如以上提到的，不僅僅在序列化上，和硬件、鏈接庫的通信也可能存在嚴格的內存布局的要求，如果你在項目設計上遭遇這些困惑，那么現(xiàn)在就可以立即動手解決它們。
如果對本文提到的序列化能力感興趣的話，可以到以下鏈接了解詳情：
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
不過在本文發(fā)布之時，以上文件所處版本沒有針對結構成員對齊選項進行修改，但并不影響閱讀。
* 補充一（2009-1-18 02:41）
聯(lián)合以及結構的結構成員對齊異常
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 類型的聯(lián)合，奇怪的是隨著全局對齊選項的修改，LARGE_INTEGER 類型本身的請求對齊 __alignof(LARGE_INTEGER) 將取聯(lián)合的成員的最大者同全局對齊選項的最小值，也就是說，當 /Zp 設置為 2，那么 LARGE_INTEGER 也將僅承諾在 2 字節(jié)邊界上對齊，多么不幸啊。當然如果將這個類型納入 #pragma pack 的限定域那就什么問題都沒有了，不管聯(lián)合的對齊算法多么的古怪，只要保證不修改所需的對齊值那將總是能獲得確定的內存布局。
不過正如上面的代碼列出的，我使用了 __int64 代替了 LARGE_INTEGER 的工作，并在請求 Win32 API 的接口上強制指針轉型，使用的時候亦如此，但若訪問聯(lián)合成員剛好為 __int64 類型則直接使用便可。這種方式?jīng)]有獲得額外的好處，算是一種抗議的行為，并且讓后來的閱讀者有機會了解到這個見不得光的問題。
_HighPerformance = ::QueryPerformanceFrequency((LARGE_INTEGER*)&_Frequency) != 0;
當然作為嚴肅的代碼寫作者，也許你將在不止一處使用到 LARGE_INTEGER，為此我也不拒絕使用如下格式：
#pragma pack(push, 8)
#include
#pragma pack(pop)
它可保證你萬無一失。
作為對比，F(xiàn)ILETIME 有如下定義：
typedef struct _FILETIME
{
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME;
且不論它所需的可能的最大結構成員對齊為 4，它也將伴隨著 /Zp 的更改而變動。因此，在不同的選項的影響下：
__alignof(LARGE_INTEGER) != __alignof(FILETIME) != __alignof(__int64)
有些人可能要指責會發(fā)生這樣的問題純粹是用戶在玩弄“結構成員對齊選項”而導致的，我真希望他能夠讀一讀這篇文章。
* 補充二（2009-1-18 02:41）
D3D 與用戶定義結構的協(xié)調
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;
};
這是一個自定義頂點結構，它的最大成員字節(jié)數(shù)為 4，所有的成員也都是 4 字節(jié)邊界，不論作何選項，始終保持緊湊存儲，若其中一個成員擴展為 8 字節(jié)，那么伴隨著選項的更改，VertexXYZ_N_T1 要求的對齊邊界可導致部分空洞，從而同硬件所需的頂點緩存數(shù)據(jù)布局存在出入，我不追究硬件是否使用 double 值，但是現(xiàn)在就應當使用
#pragma pack(push, 4)
...
#pragma pack(pop)
加以限定。
我還定義了 Matrix, Material, Vector3, Colorf 等類型，如果要使得這些數(shù)據(jù)同 D3D, D3DX 的相應類型在內存上兼容的，也是需要限定的。