在許多廣泛應(yīng)用的程序庫(kù)，我們會(huì)看到類似 #pragma pack(push, 4) 等這樣的標(biāo)示。因?yàn)橛脩魰?huì)任意更改他們的結(jié)構(gòu)成員對(duì)齊選項(xiàng)，對(duì)于先于這些內(nèi)容創(chuàng)建的程序庫(kù)來(lái)說(shuō)，不能確保一定的內(nèi)存布局將可能在預(yù)先書(shū)寫(xiě)的一些數(shù)據(jù)訪問(wèn)模塊上導(dǎo)致錯(cuò)誤，或者根本不可能實(shí)現(xiàn)。

我在實(shí)現(xiàn)一種C++ 類的實(shí)例的序列化工具時(shí)，依賴了內(nèi)存布局。我知道市面上很多“序列化”工具允許更為廣泛的通信用途，但是它們也是用起來(lá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)了一些接口，為基類訪問(wèn)當(dāng)前類型信息提供幫助。這是較早書(shū)寫(xiě)的一種方案，現(xiàn)在我會(huì)改用模板以便在編譯時(shí)建立類型信息，不過(guò)原理完全一樣。

現(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ě)編譯器選項(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è)作用域，不管該作用域通過(guò) #pragma pack(n) 聲明或者 #pragma pack(push, n)。而 #pragma pack() 總是取預(yù)設(shè)值。對(duì)于用戶事先指定了一個(gè)“子域”，并在其中引入了一個(gè)使用 #pragma pack(n) - #pragma pack() 對(duì)而非堆棧形式來(lái)聲明局部結(jié)構(gòu)成員對(duì)齊的頭文件，會(huì)使用戶非常困惑。<d3d9types.h> 就是這樣做的。

當(dāng)我們?yōu)槌绦驇?kù)編譯運(yùn)行時(shí)，有一些類型要求嚴(yán)ge地遵守內(nèi)存布局，比如一些硬件允許我們傳入的數(shù)據(jù)就需要這么做，就可以把它們限定起來(lái)：

#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"));

這就是全部了，但是正如以上提到的，不僅僅在序列化上，和硬件、鏈接庫(kù)的通信也可能存在嚴(yán)ge的內(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

不過(guò)在本文發(fā)布之時(shí)，以上文件所處版本沒(méi)有針對(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)的最小值，也就是說(shuō)，當(dāng) /Zp 設(shè)置為 2，那么 LARGE_INTEGER 也將僅承諾在 2 字節(jié)邊界上對(duì)齊，多么不幸啊。當(dāng)然如果將這個(gè)類型納入 #pragma pack 的限定域那就什么問(wèn)題都沒(méi)有了，不管聯(lián)合的對(duì)齊算法多么的古怪，只要保證不修改所需的對(duì)齊值那將總是能獲得確定的內(nèi)存布局。

不過(guò)正如上面的代碼列出的，我使用了 __int64 代替了 LARGE_INTEGER 的工作，并在請(qǐng)求 Win32 API 的接口上強(qiáng)制指針轉(zhuǎn)型，使用的時(shí)候亦如此，但若訪問(wèn)聯(lián)合成員剛好為 __int64 類型則直接使用便可。這種方式?jīng)]有獲得額外的好處，算是一種抗議的行為，并且讓后來(lái)的閱讀者有機(jī)會(huì)了解到這個(gè)見(jiàn)不得光的問(wèn)題。

_HighPerformance = ::QueryPerformanceFrequency((LARGE_INTEGER*)&_Frequency) != 0;

當(dāng)然作為嚴(yán)肅的代碼寫(xiě)作者，也許你將在不止一處使用到 LARGE_INTEGER，為此我也不拒絕使用如下格式：

#pragma pack(push, 8)
#include <windows.h>
#pragma pack(pop)

它可保證你萬(wàn)無(wú)一失。

作為對(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ā)生這樣的問(wèn)題純粹是用戶在玩弄“結(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)存上兼容的，也是需要限定的。