• <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>

            C++ Space

            C++, 3DGame

            2007年4月20日 #

            關(guān)于DLL中對(duì)象的動(dòng)態(tài)創(chuàng)建與刪除的問題

            最近有看到一些文章討論怎樣輕松的使用DLL,其中有一個(gè)錯(cuò)誤,那就是在DLL中創(chuàng)建的對(duì)象未在DLL中刪除,如下示:

            //someheadfile.h
            #include<memory>

            class __declspec(dllexport) Interface
            {
             
            public:
              virtual 
            void foo() = 0;
            }
            ;

            class __declspec(dllexport) Impl : public Interface
            {
             
            public:
               virtual 
            void foo()
               
            {}
            }
            ;

            __declspec(dllexport)
            std::auto_ptr
            <Impl> DLLCreate()
            {
              
            return std::auto_ptr<Impl>(new Impl);
            }

            上面的做法貌似可以做到自動(dòng)刪除動(dòng)態(tài)生成的對(duì)象,但,只有DLL和用戶都動(dòng)態(tài)鏈接C/C++運(yùn)行庫(kù)時(shí)它才會(huì)運(yùn)行正確,否則,創(chuàng)建和刪除會(huì)在不同的堆??臻g進(jìn)行,從而導(dǎo)致錯(cuò)誤 。
            所以還是老實(shí)的在提供一個(gè)
            DLLDelete()用于刪除在DLL中生成的對(duì)象。

            posted @ 2007-04-20 13:35 Kooyu 閱讀(1578) | 評(píng)論 (6)編輯 收藏

            2007年4月3日 #

            一個(gè)浮點(diǎn)數(shù)表示產(chǎn)生的問題

            半夜里剛睡著又被電話叫醒,一個(gè)項(xiàng)目的現(xiàn)場(chǎng)數(shù)據(jù)出現(xiàn)了錯(cuò)誤。
            我們的程序要分析的報(bào)告里的某一個(gè)字段使用了定點(diǎn)小數(shù)的表示方法,即兩個(gè)字節(jié)表示整數(shù)部分,再兩個(gè)字節(jié)表示小數(shù)部分。剛開始的時(shí)候沒注意到這里有個(gè)問題,那就是這種表示法要求小數(shù)部分一定是定長(zhǎng)的,否則,就無法解析。例如,0.03和0.30的表示不同在哪里,0.30可不可以表示成0.300。怪我當(dāng)初考慮欠佳,失敗。

            posted @ 2007-04-03 00:27 Kooyu 閱讀(980) | 評(píng)論 (0)編輯 收藏

            2007年3月9日 #

            ACE_CDR::mb_align(ACE_Message_Block * mb)使用問題

            ACE_CDR::mb_align(ACE_Message_Block * mb)用于對(duì)齊mb內(nèi)部數(shù)據(jù)塊ACE_Data_Block所擁有的內(nèi)存的起始地址,它的實(shí)現(xiàn)大致如下:

            void
            ACE_CDR::mb_align?(ACE_Message_Block?
            * mb)
            {
            ??char?
            * ? const ?start? = ?ACE_ptr_align_binary(mb -> base?(),???ACE_CDR::MAX_ALIGNMENT);

            ??mb
            -> rd_ptr?(start);
            ??mb
            -> wr_ptr?(start);
            }

            由于要執(zhí)行內(nèi)存地址對(duì)齊,那么mb->base()所指示的地址可能需要向后移動(dòng)(MAX_ALIGMENT - mb->base() % MAX_ALIGMENT)個(gè)字節(jié)。但在這個(gè)之后,mb->base()指向的可用內(nèi)存將比它自己薄記的少,如果需要程序正常運(yùn)行,那么依賴于在往它寫入數(shù)據(jù)時(shí),寫入的字節(jié)數(shù)不能大于實(shí)際大小(這個(gè)實(shí)際大小為 :mb的薄記大小-移動(dòng)的距離),而這需要由程序員來控制,容易出錯(cuò)也就難免了。

            也許可以在函數(shù)mb_align內(nèi)部重設(shè)mb的大小,使其薄記大小與實(shí)際有效內(nèi)存大小相符,但這引起內(nèi)存拷貝,這個(gè)代價(jià)也太大了。

            內(nèi)存對(duì)齊的處理似乎應(yīng)該在內(nèi)存分配階段,比如提供類似下面的分配已對(duì)齊地址功能的分配器:

            struct?Align_Alloc
            {
            ????void?
            * ?align_alloc(size_t?size,?unsigned?align)
            ????{
            ????????void?
            * ?ptr? = ? new ?char[size? + ?align];
            ????????return?align_mb_ptr(ptr,?align);
            ????}
            };

            但ACE實(shí)際上沒這么做,它提供mb_align這個(gè)與內(nèi)存分配毫不相干的功能,且希望由程序員自己來解決可能引發(fā)的問題!~
            ?

            posted @ 2007-03-09 15:33 Kooyu 閱讀(1615) | 評(píng)論 (0)編輯 收藏

            2007年3月7日 #

            "危險(xiǎn)"的函數(shù)指針類型的強(qiáng)制轉(zhuǎn)換

            查看一個(gè)與別人合作的項(xiàng)目的代碼,發(fā)現(xiàn)了一個(gè)“隱秘”的問題,模擬這個(gè)問題如下:

            typedef?void?( * foo_type)( int ,? int );

            void?foo1(
            int ,? int )
            {
            }

            void?foo2()
            {
            }

            int ?main()
            {
            ??foo_type?f?1
            = ? & foo1;??????????????????????// <1>
            ??foo_type?f?2
            = ?(foo_type) & foo2;?? // <2>
            ???? return 0;
            }
            語句<1>肯定是對(duì)的,語句<2>強(qiáng)轉(zhuǎn)一個(gè)函數(shù)類型到foo_type類型,我當(dāng)時(shí)擔(dān)心這會(huì)不會(huì)導(dǎo)致下面的語句導(dǎo)致運(yùn)行時(shí)錯(cuò)誤:
            (*f2)(1,2);

            幸運(yùn)時(shí)這里它不會(huì)導(dǎo)致錯(cuò)誤,這是由于:
            <1>我們使用C/C++的默認(rèn)函數(shù)調(diào)用方式__cdecl,也就是傳入的函數(shù)參數(shù)是由調(diào)用者清理的;
            <2>函數(shù)foo2沒有使用任何參數(shù)。
            這種做法肯定不值得提倡,但實(shí)際的項(xiàng)目中要避免還是不太容易,畢竟每個(gè)人的習(xí)慣不一樣,還有為了與框架協(xié)同工作,有時(shí)候可能也不得不這樣做。但是,一旦函數(shù)調(diào)用方式發(fā)生改變,或者被強(qiáng)轉(zhuǎn)的那個(gè)函數(shù)是帶參數(shù)的,而它又使用了這些參數(shù),隱秘的錯(cuò)誤也就埋下了。

            posted @ 2007-03-07 13:38 Kooyu 閱讀(3076) | 評(píng)論 (1)編輯 收藏

            2007年3月6日 #

            實(shí)在讓人無法忍受

            C++ = VC++ = MFC/ATL/COM
            我已經(jīng)記不清多少次看到與此類似甚至比這更離譜的關(guān)于C++的表述,真是害人不淺,特別是對(duì)C++新手而言。
            還有一些C++的半調(diào)子動(dòng)輒批評(píng)、諷刺他們一知半解的C++特性,拿C++與另一種毫不相干的語言大肆比較,得出稀奇古怪的結(jié)論。

            一些氣話,心情不好。

            posted @ 2007-03-06 13:17 Kooyu 閱讀(2304) | 評(píng)論 (7)編輯 收藏

            僅列出標(biāo)題  
            久久人人爽人人爽人人片AV不| 久久国产劲爆AV内射—百度| 伊人丁香狠狠色综合久久| 精品久久一区二区三区| 久久最近最新中文字幕大全| 色婷婷噜噜久久国产精品12p | 久久九九有精品国产23百花影院| 国产精品九九九久久九九| 久久久久亚洲精品男人的天堂| 日韩电影久久久被窝网| 狠狠狠色丁香婷婷综合久久五月| 人妻无码久久精品| 国产精品一久久香蕉国产线看| 精品欧美一区二区三区久久久| 新狼窝色AV性久久久久久| 久久国产精品视频| 国产精品福利一区二区久久| 亚洲中文久久精品无码ww16| 国产一区二区精品久久岳| 久久精品国产99国产电影网| 久久久无码一区二区三区| 性做久久久久久免费观看| 66精品综合久久久久久久| 99久久99这里只有免费费精品| 伊人色综合九久久天天蜜桃| 国产午夜电影久久| 日韩一区二区久久久久久| 久久天堂AV综合合色蜜桃网| 亚洲午夜无码久久久久| 波多野结衣久久精品| 伊人久久一区二区三区无码| 亚洲国产精品综合久久一线| 久久久久亚洲AV综合波多野结衣| 国产成人久久777777| 伊人久久大香线蕉影院95| a级毛片无码兔费真人久久| 免费观看久久精彩视频| 97精品伊人久久久大香线蕉| 国产精品嫩草影院久久| 久久久久久亚洲精品无码| 久久婷婷人人澡人人爽人人爱|