首先一個原則是這樣：被用來delete的指針，一定是new出來的。
在設計智能指針的時候發現，如果采用delete this機制，到最后可能會有嚴重的問題。
假設有這樣的多重繼承：
class CA{};
class CB{};
class CC{};
class CABC : public CA, public CB, public CC
{};
CABC* pAbc = new CABC;
CA* pA = pAbc;
CB* pB = pAbc;
CC* pC = pAbc;
A B C指針的值都是不一樣的，如果是簡單的使用delete 來刪除，問題就大條了，pB pC的地址和new出來的pAbc不一樣，這樣就出現堆錯誤。
如果設計入侵式RefObj問題就大條了：
class Ref
{
public:
virtual void Test()
{
std::cout << this << std::endl;
}
int m_i;
};
class CA : public virtual Ref{};
class CB : public virtual Ref{};
class CC : public virtual Ref{};
class CABC : public CA, public CB, public CC{};
C* pAbc = new CABC;
CA* pA = pAbc;
CB* pB = pAbc;
CC* pC = pAbc;
通過打印可以看到，雖然ABC 在基類Test打印出來的this地址一致，但是和實際正確的delete指針（new出來的）是不一致的，這就準備堆錯誤了，，，
這基本意味著使用入侵式樣Ref的類，使用了多重繼承就是作死。除非和com的思想一樣，Ref不是作為基類處理，而是作為純虛接口，但是又會使得編碼復雜化，基本上全部要用組合來替代繼承
class IXXX;
class CXXX;
class IYYY;
class CYYYXXX : public CXXX, public IYYY;
這樣的用法無法實現，應為沒有實現IXXX接口，是一個虛基類，實現了在調用的時候也是各種基類未指定的錯誤。
奇怪的是shared_ptr沒有這個限制，猜測是在第一次從裸指針構造出來的時候，保留了原始地址，生成了一個析構函數，會在shared_ptr之間共享，直到最后一個對象析構的時候調用.
實際觀察std::shared_ptr的實現，發現其構造函數不是控制一定要轉換成T指定的類型，而是給入參數的實際類型，后面的管理也分兩個部分，一層得到根據T轉換后的值，實際的生命周期管理得到仍然是實際類型，所以他delete的時候還是當初給定的值。
所以，感覺智能指針不是什么好東西，背后的細節太多，一個不小心就死翹翹
class RefObj
{
public:
RefObj() : m_i(0){}
public:
void Increate(){m_i++;}
void Decreate()
{
if(0 == --m_i)
{
delete this;
}
}
private:
int m_i;
};
class BaseA : public virtual RefObj {public: int m_iA;};
class BaseB : public virtual RefObj {public: int m_iB;};
class BaseC : public virtual RefObj {public: int m_iC;};
class CBaseABC : public BaseA,
public BaseB,
public BaseC
{
};
void Test(BaseB* pB)
{
pB->Decreate();
}
int _tmain(int argc, _TCHAR* argv[])
{
ETcpSocket tcpSocket;
CBaseABC* pABC = new CBaseABC;
pABC->Increate();
BaseB* pB = pABC;
Test(pB);
return 0;
}
始終還是覺得相比shared_ptr，RefObj這種，還是有部分場景更加格式，至少不用擔心類型轉換變得異常麻煩，，，
后發現如下實現方式：
class IRefObj
{
public:
virtual void __DecRef() = 0;
};
template<typename TType>
class TRefObj : public IRefObj
{
public:
void __DecRef()
{
delete reinterpret_cast<TType*>(this);
}
};
class CRefTest : public TRefObj<CRefTest>
{
};
class CRefTestA : public CRefTest
{
};
class CTestA {int i;};
class CTestB {int j;};
class CTestC : public CTestB, public CRefTestA, public CTestA
{
};
int _tmain(int argc, _TCHAR* argv[])
{
CTestC* pTC = new CTestC;
CTestB* pTB = pTC;
CRefTestA* pRTA = pTC;
CTestA* pTA = pTC;
pRTA->__DecRef();
這個時候CRefTest是預期額值，懷疑可能和編譯器有關，VS測試OK，gcc沒去實驗。
分析了一下原因：C++保證單根繼承的時候基類和派生類地址是一樣的，如果是多重繼承，那么也保證和最深的根父類地址樣，順便的，從最深的根節點，選一路下來是安全的。
class CRefTest : public TRefObj<CRefTest>所以約定TRefObj<CRefTest>這玩意和永遠和接口在一個級別，可以保證IRefObj永遠是最深的根，就安全了？
目前只在控件設計的時候用RefObj吧，，，坑的比較深，，，