• <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>
            posts - 297,  comments - 15,  trackbacks - 0
            出處 http://www.shnenglu.com/cexer/archive/2008/07/05/55419.html

            世界上有個叫__uuidof的關(guān)鍵字。這是一個家喻戶曉且其被廣泛使用的關(guān)鍵字,幾乎可以說,有COM程序員的地方,就有它 __uuidof的存在。其很好很強大的程度是人所共見的,夸張一點比喻:離開它的COM程序員,就像失去了點火器的火箭,雖然可以人工點火,但是不安全 且無效率。

              不過很多人并不知道,這其實是一個編譯器擴展關(guān)鍵字,提供了此關(guān)鍵字的僅VC一家別無它店。幸運的是,強大的C++讓我們能夠輕易仿真出這個關(guān)鍵字的大部分功能。

              網(wǎng)上能夠找到一種仿真的方法,見許式偉:《仿真VC++提供的關(guān)鍵字__uuidof》。該方法的實現(xiàn)是:特化模板類的成員函數(shù),然后運行時調(diào)用函數(shù)根據(jù)UUID字符串產(chǎn)生出UUID,由于是生成于運行時,所以它無可避免地有兩個缺點:

            • 存在運行時消耗。
            • 無法作為非類型模板參數(shù)傳遞給模板。

              那些整天流著口水追求效率的C++程序員們,是不能忍受任何不必要的運行時消耗的。對于第二點,VC的關(guān)鍵字__uuidof取出來的UUID 是能夠作為非類型模板參數(shù)傳遞的,ATL中就大量地使用了這樣的參數(shù)傳遞形式,所以目前的這種實現(xiàn)功能有限,仿真度還不夠高。

              其實只要能讓它能夠編譯期決定UUID的值,那么這兩個問題就迎刃而解了。而這是肯定可以實現(xiàn)的,并且很簡單。我曾經(jīng)在自己寫的一個COM庫里實現(xiàn)過這樣的方法,雖然那個庫已經(jīng)不知丟到哪里去了,不過那個方法還記得。

              解決的途徑還是離不開模板特化。類的成員包括成員函數(shù)和成員變量,函數(shù)是運行時作用的,然而static const的成員變量可以是編譯期就決定。所以解決的方法就在眼前了:特化模板的成員變量。

              以下是我的實現(xiàn)方法。

              先定義一個類模板,它有一個static const ,UUID類型的成員變量:

                template<typename T>   
            struct _uuid_of_impl
            {
            static const UUID id;
            };
            template<typename T>
            const UUID _uuid_of_impl<T>::id=GUID_NULL;

              有了這個簡單的東西就好辦了,只需要針對某個接口特它的成員變量就行了,如:

                template<>    
            const UUID _uuid_of_impl<IUnknown>::id=IID_IUnknown;

            template<>
            const UUID _uuid_of_impl<IDispatch>::id=IID_IDispatch;


              然后我們就可以這樣取得接口的UUID:

                IID IunknownID=_uuid_of_impl<IUnknown>::id;   
            IID IdispatchID=_uuid_of_impl<IDispatch>::id;


              作為非類型模板參數(shù)傳遞:

                template<const IID* t_iid>   
            struct __uuid_of_test
            {
            __uuid_of_test()
            {}

            void test()
            {
            t_iid;
            }
            };

            __uuid_of_test<&(_uuid_of_impl<IDispatch>::id) > obj;


              不過現(xiàn)在這種實現(xiàn)還有一些問題,看以下代碼:

                IID ITypelibID=_uuid_of_impl<ITypeLib>::id;


              注意我們并沒有事先對模板__uuid_of_impl特化ITypeLib的版本。但是以上語句卻能夠編譯通過,在運行時, __uuid_of_impl<ITypeLib>的值將會是錯誤的值GUID_NULL。這是因為,我們定義模板的時候,同時在模板外定義 了模板的靜態(tài)成員變量并賦值為GUID_NULL,所以沒有用特化的方法定義UUID的接口,都將使用GUID_NULL這個通用值。這當(dāng)然不是我們想要 的。所以我們想在沒有定義UUID的時候讓編譯器警告我們,要達到這樣的效果只需要去掉上面那句:

                template<typename T>   
            const UUID _uuid_of_impl<T>::id=GUID_NULL;


              現(xiàn)在再進行編譯,編譯器會告訴你,有一個無法解析的符號。根據(jù)編譯器提供的相關(guān)信息,很容易就能確定問題所在。這樣能夠在編譯期極大地減小安全隱患。

              最后加上我們定義的幾個宏,這是最后的全部實現(xiàn):

                template<typename T>   
            struct _uuid_of_impl
            {
            static const UUID id;
            };

            #define uuid_of(x) _uuid_of_impl<x>::id
            #define DEFINE_UUID(x,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \
            template<> \
            const UUID _uuid_of_impl<x>::id={l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}


              用以下代碼測試通過:

                struct ITest{};   

            DEFINE_UUID(ITest,0x96289151,0xf059,0x4049,0x88,0x19,0x61,0xa6,0xe9,0x79,0xc,0xf1);

            template<const IID* t_iid>
            struct uuid_of_test
            {
            uuid_of_test(){}
            };

            int main()
            {
            IID xxxxID=uuid_of(ITest);
            uuid_of_test<&(uuid_of(ITest))> obj;

            return 0;
            }


              需要注意的是DEFINE_UUID應(yīng)該在實現(xiàn)文件(*.cpp,*.cxx,……)當(dāng)中使用。到這里,仍有一些使用方法與VC的關(guān)鍵 字是不一樣的,所以仍沒做到仿真度100%。不過我相信通過預(yù)處理元編程,能夠相當(dāng)程度地逼近它,只是我對預(yù)處理元編程不是很了解,所以就不在這里獻丑 了。

            posted on 2008-07-19 14:03 chatler 閱讀(836) 評論(0)  編輯 收藏 引用 所屬分類: VC_MFC
            <2009年5月>
            262728293012
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(10)

            隨筆分類(307)

            隨筆檔案(297)

            algorithm

            Books_Free_Online

            C++

            database

            Linux

            Linux shell

            linux socket

            misce

            • cloudward
            • 感覺這個博客還是不錯,雖然做的東西和我不大相關(guān),覺得看看還是有好處的

            network

            OSS

            • Google Android
            • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
            • os161 file list

            overall

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            中文字幕亚洲综合久久| 久久热这里只有精品在线观看| 久久久久一本毛久久久| 91久久精品电影| 国产精品成人99久久久久91gav| 国产精品一久久香蕉国产线看观看| 久久精品一区二区三区AV| 狠狠色丁香久久婷婷综合| 久久无码国产专区精品| 久久久久亚洲AV片无码下载蜜桃| 亚洲国产精品无码久久九九| 亚洲欧美一级久久精品| 思思久久好好热精品国产| 久久天天躁狠狠躁夜夜躁2014| 久久久亚洲AV波多野结衣| 久久久无码精品亚洲日韩按摩 | 精品国产91久久久久久久a | 久久se精品一区二区| 97精品伊人久久久大香线蕉| 久久久久这里只有精品| 97久久婷婷五月综合色d啪蜜芽| 久久亚洲私人国产精品| 国产 亚洲 欧美 另类 久久| 日日狠狠久久偷偷色综合96蜜桃| 综合网日日天干夜夜久久| 粉嫩小泬无遮挡久久久久久| 久久精品国产色蜜蜜麻豆| 天堂久久天堂AV色综合| 国产午夜福利精品久久| 久久久久av无码免费网| 7国产欧美日韩综合天堂中文久久久久| 国产成人无码精品久久久免费| 污污内射久久一区二区欧美日韩| 午夜天堂av天堂久久久| 成人国内精品久久久久影院VR| 久久人人爽人人爽人人片av麻烦| 久久免费美女视频| 久久精品欧美日韩精品| 人妻无码精品久久亚瑟影视 | 久久人人爽人人爽人人AV| 久久精品成人免费国产片小草 |