• <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 - 9,  comments - 9,  trackbacks - 0

            有子曰:其為人也孝弟,而好犯上者,鮮矣;不好犯上,而好作亂者,未之有也。君子務本,本立而道生。孝弟也者,其為仁之本與。

                                                                                                  --《論語今解·學而第一》

             若要達到一個目標,必須循其根本,根本如能確定(本立),那么便容易找出解決的方法(道生)。很多時候就是這樣的道理,遇到一個問題,要追究到底才是,更何況是我們做技術的,記得第一次看見這個“本立道生”的詞的時候是在候捷翻譯的《Inside C++ Object Model》這個是作為他的序言的標題的。其實當你真的了解很多細節的時候你才能真正的體會到技術的魅力,而不是代碼的奴隸!

             前幾天去微軟面試的時候,當時那個主考官問我什么叫overload operator()?以及如何區分它和callback?當時回答的時候,我是這么想的,我是沒有用過這個仿函數啦,但是我知道仿函數是怎么實現的,就是通過重載operator()的方法實現的,而至于callback那么肯定就是通過函數指針去實現了。當時我的第一反應就是可能這個performance算是一個吧,我就這么說了,這個operator()可能是作為inline展開了,節省了函數調用的時間,提高了性能。  但是如果是callback的話,就不可能是作為inline展開了。當時也就這么回答了。主考官給我的回復是這樣的,其實至于performance這一塊來講了,也不是最主要的影響,關鍵的地方在于這個operator()可以保存調用的狀態或標志什么的私有數據,而callback只能用static的變量來取代,但是不好的還是static只能為所有的代碼服務,而overload operator()可以為每一個obj保存私有數據部分。他說了,對的,顯然他說的是沒錯。但是當時心中還是對他關于performance的回答有點疑慮,當時由于是在面試,也沒有多想下去,后來仔細想來,其實最關鍵的還是這個performance,眾所周知,如果一個class member function可以作成inline的屬性的,當然編譯器有權利決定在調用點是否內聯展開,其實在大多數的情況下面,試想如下的代碼情況:
             
            Class Compare
            {
            public:
                bool operator (
            int iFrst, int iSecond) const
               
            {
                
            // Do some thing
                return false// Or true
               
            }

            };


            // SortList(List& list, int iSize, const Compare& compareObj)
            SortList(list, 1000, com);

            如上面的所示,這個class的重載的operator()顯然就是帶有inline的屬性了,這個時候編譯器能做的是在能夠確定對象類型的時候如果這個代碼不是太大(當然還要求你的編譯器內聯選項容許狀態)那么就會在調用點內聯展開。但是如果是callback呢?肯定不是,因為他用到了函數指針,即使是這個函數定義成了inline,這個時候也不會做內聯展開的(這個時候會有生成一個類似全局的函數代碼塊,回掉的指針就指向這個塊,編譯器會維護這個代碼塊的唯一性)。所以,如果要是仿函數要求確保內聯展開的會,要唯一確保的是,代碼中的調用點應該是可以確定類型的,能夠做內聯展開。然后,這個仿函數大多數情況下是沒有多態以及繼承伴隨左右的,所以這個performance是很重要的區別之一,尤其是在你需要處理大量的同類數據的時候,比如上面的這個例子,如果iSize很大,甚至是上萬的,那么這個時候的performance估計差別就會太大了。也許你的CPU頻率更高,但是更多的是可能是這個沒有必要的損失。呵呵。

            小提示:如何判斷一個函數調用是否被內聯展開?
            方法:1.你當然可以生成匯編,自己去看。2.你可以在調用點設置斷點,看看能不能跟進去?(內聯的debug不能跟進去函數,至少目前我所知道的編譯器是這樣的)。3.當然更多的時候在調用點設置斷點,然后查看匯編代碼才是最權威的,也是比較簡單的方法。
            posted on 2007-04-18 15:30 MicroYang 閱讀(550) 評論(2)  編輯 收藏 引用

            FeedBack:
            # re: 本立道生
            2012-03-02 18:36 | 佚名
            理解有誤。函數對象可實現函數指針不能實現的功能才是主要的。  回復  更多評論
              
            # re: 本立道生[未登錄]
            2012-04-01 16:42 | zxx
            極端情況下,容器的size很大,inline帶來的performance的提高不可忽視。但是問題問的是仿函數普遍的優點。能保存數據才是標準answer  回復  更多評論
              
            <2012年3月>
            26272829123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(1)

            隨筆檔案

            Friend

            • Catherine
            • 深海羚羊
            • 似雨打芭蕉,似風吹梧桐葉,帶著一絲冰冷,也帶著一絲清新------冰柔語絲

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲综合伊人久久大杳蕉| 亚洲AV无码一区东京热久久 | 色成年激情久久综合| 久久强奷乱码老熟女网站| 青草国产精品久久久久久| 久久精品国产黑森林| 精品精品国产自在久久高清| 久久综合偷偷噜噜噜色| 久久国产精品国产自线拍免费| 久久亚洲AV成人无码软件| 九九久久精品国产| 国产亚洲精久久久久久无码 | 国产精品一区二区久久不卡| 欧美激情精品久久久久久久九九九 | 亚洲精品成人网久久久久久| 久久精品国产免费观看| 久久亚洲AV无码西西人体| 久久久久四虎国产精品| 国产精品99久久99久久久| 老男人久久青草av高清| 亚洲精品无码久久久久AV麻豆| 国产伊人久久| 久久久精品波多野结衣| 国产激情久久久久影院老熟女| 99久久人妻无码精品系列蜜桃| 日韩精品久久无码中文字幕| 亚洲中文久久精品无码ww16 | 亚洲天堂久久精品| 97久久久精品综合88久久| 久久精品www人人爽人人| 久久水蜜桃亚洲av无码精品麻豆| 国产成人久久精品一区二区三区 | 精品国产综合区久久久久久 | 少妇人妻综合久久中文字幕| 午夜精品久久影院蜜桃| 国内精品伊人久久久久777| 777午夜精品久久av蜜臀| 久久夜色精品国产噜噜噜亚洲AV| 国产美女久久精品香蕉69| 天天综合久久久网| 天天影视色香欲综合久久|