雖然沒有現(xiàn)實意義，但對理解C++的對象模型是很有幫助的。
前幾天，在論壇里看到一個帖子，內(nèi)容是：
（原帖見：http://community.csdn.net/Expert/topic/5014/5014384.xml?temp=.3018152）
========================================
class a
{
private:
int k;
};
要求不用友元，不在這個類里添加任何代碼，去訪問成員變量k。
能做出的高手，請貼出完整源碼，以便大家測試。
========================================
這道題目本身所要解決的問題并沒有多少現(xiàn)實意義，但如果試著去解決它，以及比它更復雜的情況，我認為至少對理解C++的對象模型是很有幫助的。
開始討論之前不得不說，這道題做為一個題目存在邏輯上的重大缺陷：“不給類增加一行代碼”，我實在想不出如何在驗正解題人所提供方案的正確性。只有一個private，難道用解題人所提供的讀出方案來驗證他自己所提供的寫入方案？你用你的方法讀出來，然后告訴我那就是你用你的方法寫進去的值——那能讓人信服嗎？所以我決定還是把問題改一改，并稍微具體化如下：
class Test {
public:
int get_value() { return value; }
private:
int value;
};
要求不用友元，不在這個類里添加任何代碼，把成員變量k的值改為100，結果自然是通過公共成員函數(shù)get_value來驗證。
“不在類里添加任何代碼”，除了
#define private public
我實在想不出其它的“偏門”方法了。那就想想不偏門的吧，論壇里好幾位朋友提供了相當于如下代碼的方法（為控制篇幅，本文中所有程序段都假設已包含了<iostream>頭文件并引入了std名字空間，必要時還有其它頭文件）：
Test t;
*(int*)&t = 100;
cout << t.get_value() << endl;
這種方式利用對象內(nèi)存布局的特點：整個類只有一個整型成員，沒有繼承或虛擬繼承，也沒有任何虛函數(shù)，那么這個對象的地址也就是它的第一個成員變量的地址，所以只需要把對象地址強轉成整型，那么獲得的就是那個成員變量的地址，然后對轉換后的地址再解引用，修改即可，在VC2003中驗證，結果是正確的。
但指針的強制轉換總給人帶來不爽，不大安全的感覺，上面那條最關鍵的語句相當于：
*reinterpret_cast<int*>(&t) = 100;
也就是說，它動用了C++語言中最“強”的指針轉換方式（說它最強，是因為沒有什么指針之間他不能轉換的）。其實我們完全可以做得更“文明”一點，方法是再定義一個聯(lián)合體，比如：
union TestInt {
Test t;
int i;
};
然后再：
TestInt ti;
ti.i = 100;
cout << ti.t.get_value() << endl;
同樣達到了目的，但實質上依據(jù)的機理跟上面的指針轉換是一致的。
這個方法沒啥大問題，就是有局限性，只能用于修改類的第一個成員，如果在value之前再加一個成員，比如：
class Test {
public:
int get_value() { return value; }
private:
char ch;
int value;
};
這種方法就不靈了。
當然，你可以手工算，認為char占一個字節(jié)，于是會試圖取對象地址再加1得到成員value的地址。但第一，這種方法無法不跨平臺跨實現(xiàn)，char及int類型在不同的平臺和編譯器實現(xiàn)中的長度都可能是不一樣的；第二，沒有考慮字對齊問題，在內(nèi)存中，value成員一般不會緊接著排布在ch之后，而是中間間開幾個字節(jié)，最后將int類型對齊到另一個位置，比如4的倍數(shù)的地址上；而更糟糕的是，字對齊不僅跟平臺相關，還跟預編譯指令，甚至編譯選項都會有關。所以，這種手工計算的方式還是放棄了吧。
有朋友提到了使用一種宏求出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類在內(nèi)存布局上不會有什么不同，通過指針轉換，很容易借助于它來修改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;
還有，厭惡指針操作的朋友仍可采用前面介紹的聯(lián)合體方法來運用這個模具類，只是這次定義的聯(lián)合體是這樣：
union TestTestTwin {
Test t;
TestTwin tw;
};
而程序是這樣：
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>），還弄出個虛析構函數(shù)來（我們都知道擁有虛函數(shù)的類會導致其實例中多一個虛表指針）。但后面會看到，虛函數(shù)對我們討論的問題影響不大，我們加上它只是想證明：只要方法足夠好，不怕對象更復雜。
那上面的模具辦法問題出在哪里呢？為什么不能同樣再搞一個類，把那個value改為public的，然后用它來“套住”原來對象中value成員呢？
原因是C++語言只保證類中同一個access section（即從一個訪問權限修飾符public/private/protected到另一個修飾符之間的部分）中定義的非靜態(tài)成員變量會按照聲明時的順序分布的內(nèi)存中，但并不保證跨越了不同access section的所有成員變量都在內(nèi)存中按聲明時的順序存放，某種編譯器完全有可能把所有的private塊都合成一塊，甚至整個給扔到所有protected成員的后邊去（雖然VC并沒這么做）。
換句話說：改掉了一個成員的訪問權限，就可能改變了對象的內(nèi)存布局。于是，改變了的模子也就不再能夠套住相應位置上的成員。
但辦法還是有，只需要將原來的改進一下：
在現(xiàn)有的C++對象模型中，為類增加一個非虛成員函數(shù)，不會改變對象的內(nèi)存布局，我們可以利用這一點來寫一個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;
驗證通過。
增加的虛函數(shù)純粹是個障眼物而已，它跟我們采用的方法幾乎沒有絲毫聯(lián)系，所以也就絲毫不用擔心虛函數(shù)對內(nèi)存分布的影響會影響到這個方法的正確性。但被它一搞，那個使用聯(lián)合體的方法這一次還真是不管用了，因為有了析構函數(shù)的類不能再放進聯(lián)合體中了——否則當聯(lián)合體實例的生命周期結束時，析構誰呢？
想了關天，能想到的只有這么多了。
最后，不行不承認，“增加一個非虛成員函數(shù)，不會改變對象的內(nèi)存布局”這句話也無法從C++標準中得到直接支持，只是對于目前大多數(shù)編譯器來說，這都是沒問題的。因為這種“讓類的每個實例擁有一份獨立的成員變量，而類的所有實例共享一份成員函數(shù)”的C++對象模型是C++之父Bjarne Stroustrup先生本人所提出的，其時間、空間效率都很好地符合了C++語言的設計初衷，不僅現(xiàn)代C++編譯器沒有不這么做的，就連Java/C#編譯器也都這么做。所以，也算是個“相對真理”了。
原文地址：http://community.csdn.net/Expert/topic/5039/5039857.xml?temp=.728924