• <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ù)  更多評論
              

            久久亚洲精品国产精品| 精品视频久久久久| 99久久精品毛片免费播放| 久久精品夜夜夜夜夜久久| 国产精品一区二区久久精品| 亚洲欧美日韩精品久久| 久久精品国产只有精品66| 狠狠色婷婷久久一区二区| 国产精品久久久福利| 久久久久18| 亚洲av伊人久久综合密臀性色| 久久精品夜夜夜夜夜久久| 国产午夜精品久久久久九九| 亚洲欧洲久久久精品| 69SEX久久精品国产麻豆| 久久久无码精品亚洲日韩软件| 久久频这里精品99香蕉久| 色婷婷综合久久久久中文一区二区| 亚洲国产成人久久综合一| 2021国产精品午夜久久| 久久99精品国产99久久| 欧美久久天天综合香蕉伊| 99国产欧美久久久精品蜜芽 | 国内精品人妻无码久久久影院 | 亚洲成av人片不卡无码久久| 无码国内精品久久人妻| 久久精品国产一区二区三区不卡| 久久久久亚洲av无码专区导航| 中文字幕久久久久人妻| 精品人妻久久久久久888| 天堂无码久久综合东京热| 国产精品久久久久影视不卡| 久久久久精品国产亚洲AV无码| 国产午夜久久影院| 久久精品www人人爽人人| 欧美亚洲另类久久综合婷婷| 久久精品免费观看| 久久婷婷五月综合色奶水99啪| 久久人人爽人爽人人爽av| 久久久久夜夜夜精品国产| 午夜久久久久久禁播电影|