在許多廣泛應用的程序庫，我們會看到類似 #pragma pack(push, 4) 等這樣的標示。因為用戶會任意更改他們的結(jié)構(gòu)成員對齊選項，對于先于這些內(nèi)容創(chuàng)建的程序庫來說，不能確保一定的內(nèi)存布局將可能在預先書寫的一些數(shù)據(jù)訪問模塊上導致錯誤，或者根本不可能實現(xiàn)。

我在實現(xiàn)一種C++ 類的實例的序列化工具時，依賴了內(nèi)存布局。我知道市面上很多“序列化”工具允許更為廣泛的通信用途，但是它們也是用起來最麻煩的，有很多限制條件。我實現(xiàn)的序列化工具用意很明顯，為特定運行模塊提供便捷高效的持久化存儲能力。

為了提供感性的認識，提供了一個使用這個序列化工具的類型定義。

class StorageDoc
        : public SerialOwner
{
public:
        Serializable(StorageDoc);

        char c;
        int i;
        SerialString str;
};

它繼承自 SerialOwner，它聲明了 Serializable，隱含著實現(xiàn)了一些接口，為基類訪問當前類型信息提供幫助。這是較早書寫的一種方案，現(xiàn)在我會改用模板以便在編譯時建立類型信息，不過原理完全一樣。

現(xiàn)在，StorageDoc 當中的內(nèi)存布局需要可確定的，但是用戶會選擇不同的結(jié)構(gòu)成員對齊選項，為此需要設定一個結(jié)構(gòu)成員對齊的“子域”，完成這項能力的偽指令是 #pragma pack。

#pragma pack( [ show ] | [ push | pop ] [, identifier ] , n  )

1）當選用 show，則添加一條警告信息，指示當前編譯域內(nèi)的對齊屬性
2）僅僅設置 n，則重寫編譯器選項 /Zp，并影響到此聲明以下的同一個編譯單元內(nèi)的所有結(jié)構(gòu)定義
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() 對而非堆棧形式來聲明局部結(jié)構(gòu)成員對齊的頭文件，會使用戶非常困惑。<d3d9types.h> 就是這樣做的。

當我們?yōu)槌绦驇炀幾g運行時，有一些類型要求嚴ge地遵守內(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)

事情再回到序列化上面，用戶會多次嘗試編譯他們的序列化應用模塊，并指望前一次編譯之后運行所產(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"));

這就是全部了，但是正如以上提到的，不僅僅在序列化上，和硬件、鏈接庫的通信也可能存在嚴ge的內(nèi)存布局的要求，如果你在項目設計上遭遇這些困惑，那么現(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ā)布之時，以上文件所處版本沒有針對結(jié)構(gòu)成員對齊選項進行修改，但并不影響閱讀。

* 補充一（2009-1-18 02:41）

聯(lián)合以及結(jié)構(gòu)的結(jié)構(gòu)成員對齊異常

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)合的對齊算法多么的古怪，只要保證不修改所需的對齊值那將總是能獲得確定的內(nèi)存布局。

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

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

當然作為嚴肅的代碼寫作者，也許你將在不止一處使用到 LARGE_INTEGER，為此我也不拒絕使用如下格式：

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

它可保證你萬無一失。

作為對比，F(xiàn)ILETIME 有如下定義：

typedef struct _FILETIME
    {
    DWORD dwLowDateTime;
    DWORD dwHighDateTime;
    }   FILETIME;

且不論它所需的可能的最大結(jié)構(gòu)成員對齊為 4，它也將伴隨著 /Zp 的更改而變動。因此，在不同的選項的影響下：

__alignof(LARGE_INTEGER) != __alignof(FILETIME) != __alignof(__int64)

有些人可能要指責會發(fā)生這樣的問題純粹是用戶在玩弄“結(jié)構(gòu)成員對齊選項”而導致的，我真希望他能夠讀一讀這篇文章。

* 補充二（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;
};

這是一個自定義頂點結(jié)構(gòu)，它的最大成員字節(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 的相應類型在內(nèi)存上兼容的，也是需要限定的。