從一個修改私有變數的問題想到的

前幾天，在論壇裡看到一個帖子，內容是：

（原帖見：http://community.csdn.net/Expert/topic/5014/5014384.xml?temp=.3018152 ）

========================================

class a
{
private:
    int k;
};

要求不用友元，不在這個類裡新增任何程式碼，去訪問成員變數k。

能做出的高手，請貼出完整原始碼，以便大家測試。

========================================

 

這道題目本身所要解決的問題並沒有多少現實意義，但如果試著去解決它，以及比它更復雜的情況，我認為至少對理解C++的物件模型是很有幫助的。

 

開始討論之前不得不說，這道題做為一個題目存在邏輯上的重大缺陷：“不給類增加一行程式碼”，我實在想不出如何在驗正解題人所提供方案的正確性。只有一個private，難道用解題人所提供的讀出方案來驗證他自己所提供的寫入方案？你用你的方法讀出來，然後告訴我那就是你用你的方法寫進去的值——那能讓人信服嗎？所以我決定還是把問題改一改，並稍微具體化如下：

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 {
    Test   t;
    int    i;
};

然後再：

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 {
    Test       t;
    TestTwin   tw;
};

而程式是這樣：

TestTestTwin ttw;
ttw.tw.value = 100;
cout << ttw.t.get_value() << endl;

問題都解決了嗎？如果類更復雜一些，會不會還有侷限性呢？我們再把類改一改：

class Test {
public:
    int get_value() { return value; }
    virtual ~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; }
    virtual ~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#編譯器也都這麼做。所以，也算是個“相對真理”了。