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