C++記憶體布局–從一個修改私人變數的問題想到的

class Test {
public:
int get_value() { return value; }
private:
int value;
};
要求不用友元，不在這個類裡添加任何代碼，把成員變數k的值改為100，結果自然是通過公用成員函數get_value來驗證。
“不在類裡添加任何代碼”，除了#define private public
我實在想不出其它的“偏門”方法了。那就想想不偏門的吧，論壇裡好幾位朋友提供了相當於如下代碼的方法（為控制篇幅，本文中所有程式段都假設已包含了<iostream>標頭檔並引入了std名字空間，必要時還有其它標頭檔）：
Test t;
*(int*)&t = 100;
cout << t.get_value() << endl;
這種方式利用對象記憶體布局的特點：整個類只有一個整型成員，沒有繼承或虛擬繼承，也沒有任何虛函數，那麼這個對象的地址也就是它的第一個成員變數的地址，所以只需要把對象地址強轉成整型，那麼獲得的就是那個成員變數的地址，然後對轉換後的地址再解引用，修改即可，在VC2003中驗證，結果是正確的。
但指標的強制轉換總給人帶來不爽，不大安全的感覺，上面那條最關鍵的語句相當於：
*reinterpret_cast<int*>(&t) = 100;
也就是說，它動用了C++語言中最“強”的指標轉換方式（說它最強，是因為沒有什麼指標之間他不能轉換的）。其實我們完全可以做得更“文明”一點，方法是再定義一個聯合體，比如：
union TestInt {
Testt;
inti;
};
然後再：
TestInt ti;
ti.i = 100;
cout << ti.t.get_value() << endl;
同樣達到了目的，但實質上依據的機理跟上面的指標轉換是一致的。
這個方法沒啥大問題，就是有局限性，只能用於修改類的第一個成員，如果在value之前再加一個成員，比如：
class Test {
public:
int get_value() { return value; }
private:
char ch;
int value;
};
這種方法就不靈了。
當然，你可以手工算，認為char佔一個位元組，於是會試圖取對象地址再加1得到成員value的地址。但第一，這種方法無法不跨平台跨實現，char及int類型在不同的平台和編譯器實現中的長度都可能是不一樣的；第二，沒有考慮字對齊問題，在記憶體中，value成員一般不會緊接著排布在ch之後，而是中間間開幾個位元組，最後將int類型對齊到另一個位置，比如4的倍數的地址上；而更糟糕的是，字對齊不僅跟平台相關，還跟先行編譯指令，甚至編譯選項都會有關。所以，這種手工計算的方式還是放棄了吧。
有朋友提到了使用一種宏求出value成員相對於整個對象起始地址的位移量，即定義一個宏：
#define OFFSET(TYPE,MEM) ((int)(char*)&(((TYPE*)0)->MEM))
這個宏通過把0地址轉換為TYPE指標類型，然後從這個指標上“取”MEM成員，而MEM成員的地址轉換後結果就是MEM成員相對於整個對象的位移量（我們既然是從0地址開始算的，就不用再減去起始地址0）。
然後同，我們通過使用這個宏作用於原來的類和目標欄位，即：
OFFSET(Test, value)
就可以獲得value欄位在Test類型對象中的位移量，用對象的首地址加上這個位移量，就可以得到value變數的地址，從而可以像上面一樣解引用，修改。
這種方法不僅看起來難受，費解。事實上也根本行不通，因為這個宏所用到的技巧是從Test類型的指標上訪問value成員——而valuee是private的！所以連編譯都通不過。

論壇裡有位朋友提出了另外一種方法可以巧妙地對付這個複雜一點的類，先做一個輔助類，它跟Test類很像，唯一的不同是它的成員都是public的：
class TestTwin {
public:
int get_value() { return value; }
public:
char ch;
int value;
};
於是，這個TestTwin類跟原來的Test類在記憶體布局上不會有什麼不同，通過指標轉換，很容易藉助於它來修改Test類對象的value成員：
Test t;
TestTwin* p = reinterpret_cast<TestTwin*>(&t);
p->value = 100;
cout << t.get_value() << endl;
如果你不熟悉C++的顯式指標轉換方式：reinterpret_cast，在這裡可以認為它相當於C風格的：
TestTwin* p = (TestTwin*)&t;
而前述的兩條語句也可以合在一起，直接寫成：
reinterpret_cast<TestTwin*>(&t)->value = 100;
還有，厭惡指標操作的朋友仍可採用前面介紹的聯合體方法來運用這個模具類，只是這次定義的聯合體是這樣：
union TestTestTwin {
Testt;
TestTwintw;
};
而程式是這樣：
TestTestTwin ttw;
ttw.tw.value = 100;
cout << ttw.t.get_value() << endl;

問題都解決了嗎？如果類更複雜一些，會不會還有局限性呢？我們再把類改一改： 
class Test {
public:
int get_value() { return value; }
~Test() {}
private:
char ch;
int value;
public:
int a;
double b;
protected:
string e;
private:
short d;
};
這次不僅成員多了許多，有string類型的成員（須include <string>），還弄出個虛解構函式來（我們都知道擁有虛函數的類會導致其執行個體中多一個虛表指標）。但後面會看到，虛函數對我們討論的問題影響不大，我們加上它只是想證明：只要方法足夠好，不怕對象更複雜。
那上面的模具辦法問題出在哪裡呢？為什麼不能同樣再搞一個類，把那個value改為public的，然後用它來“套住”原來對象中value成員呢？
原因是C++語言只保證類中同一個access section（即從一個存取權限修飾符public/private/protected到另一個修飾符之間的部分）中定義的非靜態成員變數會按照聲明時的順序分布的記憶體中，但並不保證跨越了不同access section的所有成員變數都在記憶體中按聲明時的順序存放，某種編譯器完全有可能把所有的private塊都合成一塊，甚至整個給扔到所有protected成員的後邊去（雖然VC並沒這麼做）。
換句話說：改掉了一個成員的存取權限，就可能改變了對象的記憶體布局。於是，改變了的模子也就不再能夠套住相應位置上的成員。
但辦法還是有，只需要將原來的改進一下：
在現有的C++物件模型中，為類增加一個非虛成員函數，不會改變對象的記憶體布局，我們可以利用這一點來寫一個TestTwin：
class TestTwin {
public:
int get_value() { return value; }
void set_value(int v) { value = v; }
~TestTwin() {}
private:
char ch;
int value;
public:
int a;
double b;
protected:
float e;
private:
short d;
};
這個模具跟原來的Test類也是只有一點不同：增加了一個公用的，非虛的set_value方法，用來給私人成員value賦值。於是，程式可以這麼寫：
Test t;
reinterpret_cast<TestTwin*>(&t)->set_value(100);
cout << t.get_value() << endl;
驗證通過。
增加的虛函數純粹是個障眼物而已，它跟我們採用的方法幾乎沒有絲毫聯絡，所以也就絲毫不用擔心虛函數對記憶體分布的影響會影響到這個方法的正確性。但被它一搞，那個使用聯合體的方法這一次還真是不管用了，因為有了解構函式的類不能再放進聯合體中了——否則當聯合體執行個體的生命週期結束時，析構誰呢？ 

想了關天，能想到的只有這麼多了。
最後，不行不承認，“增加一個非虛成員函數，不會改變對象的記憶體布局”這句話也無法從C++標準中得到直接支援，只是對於目前大多數編譯器來說，這都是沒問題的。因為這種“讓類的每個執行個體擁有一份獨立的成員變數，而類的所有執行個體共用一份成員函數”的C++物件模型是C++之父Bjarne Stroustrup先生本人所提出的，其時間、空間效率都很好地符合了C++語言的設計初衷，不僅現代C++編譯器沒有不這麼做的，就連Java/C#編譯器也都這麼做。所以，也算是個“相對真理”了。
研究一下這個例子，卻有助於加深對C++物件模型的理解