類成員之間依賴導致的BUG

今天調查一個程式崩潰的bug，最後的結果是類成員之間的依賴導致的析構問題。

 

問題描述如下：

類A有兩個成員，類B和類C的執行個體各一個，其中成員b依賴於成員c

 

class A

{

    classA()

   {

       mb.setC(&mc);

   }

    classB  mb;

    classC  mc;

};

 

而類B又有類似下面的解構函式

    ~classB()

    {

       mc->fun();

   }

 

當Ａ的執行個體析構時，由於類B的析構發生在類C之後，因此類B析構導致程式崩潰。這個bug更噁心的地方是，由於mc不是以指標的形式存在的，因此B的析構裡面實際是對一個已經析構的記憶體做操作，得出的是為定義的結果。

 

解決方案：

1。可以通過調整mb和mc的順序。但這是依賴於編譯器的特性來解決一個程式邏輯問題，並不佳。

2。將mb和mc的類型改為指標，然後再類A的解構函式裡面顯示地保證mb和mc的析構順序。

 

題外話：

      1。如果類B的整個生命週期都依賴於類C的話，建議及那個類C的執行個體作為類B的建構函式參數來傳遞，這樣可以強調出類B對該對象的依賴，當別人看到該代碼時就能對此產生警覺。 

      2、更進一步，如果ClassB不是組合依賴於ClassC的話，那麼ClassB在解構函式中調用ClassC來進行清理的做法就值得商榷。如果可以的話，相關清理應該放到ClassC自己的解構函式中。