• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 304357
            • 排名 - 84

            最新評論

            閱讀排行榜

            估計標題和摘要都說不清楚,先直接用以前的一個demo說明一下多態吧。
            demo中有一個terrain類,代表地形,地形要做的工作就是調整player和enemy的高度,以便讓它們看起來是正確的站在地面上。
            負責這個工作的函數是CTerrain::Support(param),現在的問題是param的類型。在設定上,無論是terrain->support(player),或者terrain->support(enemy),Support函數內所做的調用是完全相似的。
            因此,第一直覺是,抽象出player和enemy的基類cast,并將被CTerrain::Support調用的函數寫成(純)虛函數。
            代碼大概是這樣子:

            class ??CCast
            {
            public :
            ??
            virtual ?? void ??DoSomething1()? = ? 0 ;
            ??
            virtual ?? void ??DoSomething2()? = ? 0 ;
            }
            ;
            class ??CPlayer?:? public ?CCast? {} ;
            class ??CEnemy?:? public ?CCast? {} ;

            class ??CTerrain
            {
            public :
            ??
            void ??Support(CCast? * cast)
            ??
            {
            ????cast
            -> DoSomething1();
            ????cast
            -> DoSomething2();
            ??}

            }
            ;

            接下來聊聊模板的表現。基于上面的代碼,把CCast類去掉,同時CPlayer和CEnemy類仍舊實現成員函數DoSomething1()和DoSomething2()。CTerrain類修改一下:
            class??CTerrain
            {
            public:
            ??template
            <typename?CAST>
            ??
            void??Support(CAST??*cast)
            ??
            {
            ????cast
            ->DoSomething1();
            ????cast
            ->DoSomething2();
            ??}

            }
            ;

            情況大概就是這樣子了,需要思考的是:
            1,模板是編譯時刻決定選擇,多態是runtime時刻決定選擇。那么,如果事務的環境允許編譯時刻決定選擇,采用模板方案是否更有意義?CEGUI在msg->handler的映射上采用了模板機制。
            2,多態有虛擬函數表的開銷,模板的實例化,同樣有類似于函數重載的開銷。不過,多態的開銷包括時間和空間上的,而模板僅僅是空間開銷。
            3,如果堅持用模板構建整個project,那么設計上就要抹去runtime時刻決定選擇的行為,這是否會增加程序復雜度,降低可擴展性?
            posted on 2006-12-20 15:37 LOGOS 閱讀(1194) 評論(3)  編輯 收藏 引用

            FeedBack:
            # re: 模版與多態 2006-12-20 20:09 pengkuny
            關注  回復  更多評論
              
            # re: 模版與多態 2006-12-21 14:48 Francis Arcanum
            如果不考慮在運行期間動態的增加邏輯的話,模板和虛函數其實是一樣的
            因為main不是模板函數,同樣C++里new T也不能變成虛函數(因為沒有反射),兩種思路歸根結底都必須在一個點上進行switch或mapping。
            模板的問題在于,它缺乏一個統一的型別,因此在對模板對象進行持有的時候會有些困難。這個問題最后還是要靠虛函數來解決。  回復  更多評論
              
            # re: 模版與多態 2006-12-22 15:43 小山日志
            一個是運行時的動態多態;一個是編譯時的靜態多態。
            一個是優先使用高內聚的類來封裝數據和算法;一個是將算法和數據分別歸類,再以接口來使用,以此提高算法和容器的利用效率(這個是STL的做法,你提出的例子好像沒有體現出來^_^)。

            關于你提出的第三點,我以為那要看你的設計如何了。泛型和多態(動態的)其實目的都是提供高內聚、低耦合的設計方法,只是側重點不一樣啊  回復  更多評論
              
            亚洲国产精品18久久久久久| 狠狠色综合久久久久尤物| 久久国产免费直播| www性久久久com| 日韩精品久久久久久久电影| 久久久久亚洲AV无码永不| 伊人色综合久久| 久久久久久无码Av成人影院| 久久五月精品中文字幕| 国产精品久久久久久福利69堂| 久久久久亚洲av成人无码电影| 久久精品国产亚洲AV蜜臀色欲| 9191精品国产免费久久| 无码人妻精品一区二区三区久久久 | 国产ww久久久久久久久久| 午夜精品久久久久久| 丁香久久婷婷国产午夜视频| 午夜精品久久久久久中宇| 亚洲精品无码久久久久AV麻豆| 久久九九亚洲精品| 99久久人妻无码精品系列蜜桃 | 国产精品成人久久久| 99久久精品免费看国产| 国产精品久久国产精品99盘 | 久久久国产视频| 久久久久国产精品三级网| 久久久国产精品网站| 国内精品伊人久久久久| 亚洲午夜久久久影院| 久久久亚洲裙底偷窥综合| 一本久久综合亚洲鲁鲁五月天| 亚洲精品国产综合久久一线| 久久亚洲中文字幕精品一区四 | 久久福利片| 久久无码精品一区二区三区| 日本亚洲色大成网站WWW久久| 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 久久久久人妻精品一区| 久久w5ww成w人免费| 国产精品99久久久久久猫咪| 国产精品九九久久精品女同亚洲欧美日韩综合区 |