• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Error

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              217 Posts :: 61 Stories :: 32 Comments :: 0 Trackbacks
            首先一個原則是這樣:被用來delete的指針,一定是new出來的。
            在設(shè)計智能指針的時候發(fā)現(xiàn),如果采用delete this機(jī)制,到最后可能會有嚴(yá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指針的值都是不一樣的,如果是簡單的使用delete 來刪除,問題就大條了,pB pC的地址和new出來的pAbc不一樣,這樣就出現(xiàn)堆錯誤。
            如果設(shè)計入侵式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出來的)是不一致的,這就準(zhǔn)備堆錯誤了,,,
            這基本意味著使用入侵式樣Ref的類,使用了多重繼承就是作死。除非和com的思想一樣,Ref不是作為基類處理,而是作為純虛接口,但是又會使得編碼復(fù)雜化,基本上全部要用組合來替代繼承
            class IXXX;
            class CXXX;
            class IYYY;
            class CYYYXXX : public CXXX, public IYYY;
            這樣的用法無法實現(xiàn),應(yīng)為沒有實現(xiàn)IXXX接口,是一個虛基類,實現(xiàn)了在調(diào)用的時候也是各種基類未指定的錯誤。

            奇怪的是shared_ptr沒有這個限制,猜測是在第一次從裸指針構(gòu)造出來的時候,保留了原始地址,生成了一個析構(gòu)函數(shù),會在shared_ptr之間共享,直到最后一個對象析構(gòu)的時候調(diào)用.
            實際觀察std::shared_ptr的實現(xiàn),發(fā)現(xiàn)其構(gòu)造函數(shù)不是控制一定要轉(zhuǎn)換成T指定的類型,而是給入?yún)?shù)的實際類型,后面的管理也分兩個部分,一層得到根據(jù)T轉(zhuǎn)換后的值,實際的生命周期管理得到仍然是實際類型,所以他delete的時候還是當(dāng)初給定的值。
            所以,感覺智能指針不是什么好東西,背后的細(xì)節(jié)太多,一個不小心就死翹翹



            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這種,還是有部分場景更加格式,至少不用擔(dān)心類型轉(zhuǎn)換變得異常麻煩,,,
            后發(fā)現(xiàn)如下實現(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();

            這個時候CRefTest是預(yù)期額值,懷疑可能和編譯器有關(guān),VS測試OK,gcc沒去實驗。
            分析了一下原因:C++保證單根繼承的時候基類和派生類地址是一樣的,如果是多重繼承,那么也保證和最深的根父類地址樣,順便的,從最深的根節(jié)點,選一路下來是安全的。
            class CRefTest : public TRefObj<CRefTest>所以約定TRefObj<CRefTest>這玩意和永遠(yuǎn)和接口在一個級別,可以保證IRefObj永遠(yuǎn)是最深的根,就安全了?
            目前只在控件設(shè)計的時候用RefObj吧,,,坑的比較深,,,
            posted on 2014-10-16 16:29 Enic 閱讀(754) 評論(2)  編輯 收藏 引用 所屬分類: C/C++技巧

            評論

            # re: C++多重繼承導(dǎo)致delete引起堆錯誤、智能指針設(shè)計陷阱[未登錄] 2014-10-17 10:58 Chipset
            這種對象指針默認(rèn)轉(zhuǎn)換中類型都丟了,析構(gòu)的時候調(diào)用哪個系夠函數(shù)?手工刪除時就死悄悄,用智能指針當(dāng)然也照樣死悄悄。何止對象這樣啊,C++里永遠(yuǎn)都是這樣,如果自己想自殺,C++絕對成全你,這是Human Right!  回復(fù)  更多評論
              

            # re: C++多重繼承導(dǎo)致delete引起堆錯誤、智能指針設(shè)計陷阱 2014-10-30 14:19 Enic
            用boost::shared_ptr 或者std::shared_ptr的時候沒有這個問題,我猜測是共享數(shù)據(jù)卡里邊保留了原始指針,,,@Chipset
              回復(fù)  更多評論
              

            亚洲国产精品嫩草影院久久| 人妻少妇精品久久| 国産精品久久久久久久| 久久人人爽人人爽人人片AV不| 欧美亚洲国产精品久久久久| 国产精品内射久久久久欢欢| 欧美亚洲另类久久综合| 久久最近最新中文字幕大全 | 久久99精品久久久久久久不卡| 久久人人爽人人人人爽AV| 中文字幕久久精品| 国内精品久久久久| 99久久婷婷国产一区二区| 久久www免费人成精品香蕉| 日产精品久久久一区二区| 久久艹国产| 久久精品国产精品亚洲精品 | 欧美喷潮久久久XXXXx| 久久久久久久国产免费看| 亚洲精品视频久久久| 色噜噜狠狠先锋影音久久| 无码国内精品久久人妻| av国内精品久久久久影院| 久久亚洲精品国产精品婷婷| 久久免费99精品国产自在现线| 亚洲va久久久久| 欧美大战日韩91综合一区婷婷久久青草| 久久99精品久久久久久久久久| 亚洲AV无码久久精品色欲| 中文字幕精品无码久久久久久3D日动漫| 国内精品伊人久久久久影院对白 | 狠狠色丁香婷婷久久综合五月| 一本一道久久综合狠狠老| 亚洲成人精品久久| 曰曰摸天天摸人人看久久久| 久久精品国产久精国产| 久久国产免费观看精品| 9999国产精品欧美久久久久久| 91精品国产综合久久香蕉| 93精91精品国产综合久久香蕉 | 人妻系列无码专区久久五月天|