首先一個(gè)原則是這樣：被用來(lái)delete的指針，一定是new出來(lái)的。
在設(shè)計(jì)智能指針的時(shí)候發(fā)現(xiàn)，如果采用delete this機(jī)制，到最后可能會(huì)有嚴(yán)重的問(wèn)題。
假設(shè)有這樣的多重繼承：
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指針的值都是不一樣的，如果是簡(jiǎn)單的使用delete 來(lái)刪除，問(wèn)題就大條了，pB pC的地址和new出來(lái)的pAbc不一樣，這樣就出現(xiàn)堆錯(cuò)誤。
如果設(shè)計(jì)入侵式RefObj問(wèn)題就大條了：
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;
通過(guò)打印可以看到，雖然ABC 在基類Test打印出來(lái)的this地址一致，但是和實(shí)際正確的delete指針（new出來(lái)的）是不一致的，這就準(zhǔn)備堆錯(cuò)誤了，，，
這基本意味著使用入侵式樣Ref的類，使用了多重繼承就是作死。除非和com的思想一樣，Ref不是作為基類處理，而是作為純虛接口，但是又會(huì)使得編碼復(fù)雜化，基本上全部要用組合來(lái)替代繼承
class IXXX;
class CXXX;
class IYYY;
class CYYYXXX : public CXXX, public IYYY;
這樣的用法無(wú)法實(shí)現(xiàn)，應(yīng)為沒有實(shí)現(xiàn)IXXX接口，是一個(gè)虛基類，實(shí)現(xiàn)了在調(diào)用的時(shí)候也是各種基類未指定的錯(cuò)誤。
奇怪的是shared_ptr沒有這個(gè)限制，猜測(cè)是在第一次從裸指針構(gòu)造出來(lái)的時(shí)候，保留了原始地址，生成了一個(gè)析構(gòu)函數(shù)，會(huì)在shared_ptr之間共享，直到最后一個(gè)對(duì)象析構(gòu)的時(shí)候調(diào)用.
實(shí)際觀察std::shared_ptr的實(shí)現(xiàn)，發(fā)現(xiàn)其構(gòu)造函數(shù)不是控制一定要轉(zhuǎn)換成T指定的類型，而是給入?yún)?shù)的實(shí)際類型，后面的管理也分兩個(gè)部分，一層得到根據(jù)T轉(zhuǎn)換后的值，實(shí)際的生命周期管理得到仍然是實(shí)際類型，所以他delete的時(shí)候還是當(dāng)初給定的值。
所以，感覺智能指針不是什么好東西，背后的細(xì)節(jié)太多，一個(gè)不小心就死翹翹
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這種，還是有部分場(chǎng)景更加格式，至少不用擔(dān)心類型轉(zhuǎn)換變得異常麻煩，，，
后發(fā)現(xiàn)如下實(shí)現(xiàn)方式：
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();
這個(gè)時(shí)候CRefTest是預(yù)期額值，懷疑可能和編譯器有關(guān)，VS測(cè)試OK，gcc沒去實(shí)驗(yàn)。
分析了一下原因：C++保證單根繼承的時(shí)候基類和派生類地址是一樣的，如果是多重繼承，那么也保證和最深的根父類地址樣，順便的，從最深的根節(jié)點(diǎn)，選一路下來(lái)是安全的。
class CRefTest : public TRefObj<CRefTest>所以約定TRefObj<CRefTest>這玩意和永遠(yuǎn)和接口在一個(gè)級(jí)別，可以保證IRefObj永遠(yuǎn)是最深的根，就安全了？
目前只在控件設(shè)計(jì)的時(shí)候用RefObj吧，，，坑的比較深，，，