• <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++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              13 隨筆 :: 0 文章 :: 69 評論 :: 0 Trackbacks

            SFINEA in C++

            作者:唐風

            原載于:www.cnblogs.com/liyiwen

               

                SFINAE(substitution failure is not a error) 主要用于模板函數(shù),它是指,編譯器在使用具體類型來替換模板類型參數(shù),對模板進行實例化(展開模板)時,如果發(fā)生替換失敗,那么并不會直接引發(fā)編譯錯誤(Error),而只是簡單地把這個模板從重載候選者中去除掉。

                還是看看代碼吧(一個在SFINAE中常遇到的例子):

                代碼段1:

                template <typename T>
                bool is_class(int T::*) {
                    return true;
                }
            
                template <typename T>
                bool is_class(...) {
                    return false;
                }
            
                struct Test {
                };
            
                int main(void) {
                    std::cout<<is_class<Test>(0)<<endl;
                    std::cout<<is_class<int>(0)<<endl;
                }
            

                運行的結果是輸出:

                1

                0

                這表明,如果傳給 is_class 的模板參數(shù)是一個類,那么返回 true 的那個版本就會被選中,否則false的那個版本會被選中。就是因為SFINAE在起作用。

            為什么要提SFINAE?

                僅僅從程序員的角度來看,程序段1中,對相應函數(shù)選擇的結果是非常符合直觀的預期,與普通函數(shù)重載是很相似的感覺。

                例如,對于下面這兩個函數(shù):

                int max(int a, int b) {return a>b?a:b}
                float max(float a, float b) {return a>b?a:b}
            
                int main(void) {
                    float x1=3.4f, x2=3.6f;
                    cout<<max(x1, x2);
                }

                  對于 float 型的參數(shù),float 版本的重載自然會很被選中。在外觀上看,程序段1是一樣的。那么為什么程序段1就需要特別的 SFNIAE 呢?

                我想,對于普通函數(shù)的重載而言,由于這些函數(shù)的所有信息都已經(jīng)完備,在發(fā)生調用之前,編譯器已經(jīng)可以完成對這些函數(shù)的編譯,這些函數(shù)也不可能再被增加任何新的信息,可以直接產(chǎn)生執(zhí)行代碼。在函數(shù)的調用點上,編譯器只需要根據(jù)參數(shù)信息選擇一個合適函數(shù)的地址就可以了。

                但是,對于模板函數(shù)重載,情況就不一樣了。我們分析下程序段1中,is_class<int>(0) 這個調用,在第一步的選擇中,無論從模板參數(shù)的個數(shù)、函數(shù)參數(shù)的個數(shù)來看,兩個 is_class 的實現(xiàn)都可能匹配,由于 int T::* (類成員指針)的匹配優(yōu)先級比 … 的要高,所以編譯器會先試圖使用第一個版本進行展開。但編譯展開的結果時發(fā)現(xiàn) int::* 是不合法的,于是編譯器就放棄展開這個函數(shù),而取另一個函數(shù)進行展開,并得到正確的調用。

               所以,在真正發(fā)生調用(應該說真正需要被展開)之前,模板函數(shù)中的信息是不完備的,編譯器無法為這些模板函數(shù)生成真正的執(zhí)行代碼,而只是進行一些很基本、簡單的檢查。所有的模板都不是“真正的代碼”,它們是編譯器用來生成代碼的工具。在需要展開的時候,編譯器從合適的候選者中選出優(yōu)先級最高的一個來進行實例化(展開)。在展開后的代碼如果不能正確被編譯(像上面例子中 int::* 這種情況),編譯器只是簡單地放棄這次展開,轉而尋找其它的模板。試想,如果編譯器在展開失敗后,直接產(chǎn)生一個編譯錯誤的話,其它的函數(shù)就沒有機會了,這是非常不合理的,因為:1.本次展開失敗并不意味著被展開的模板代碼就有問題,因為用其它類型的話還是有可能展開成功的。2.本次展開失敗并不代表用于展開的類型無法找到合適的模板,其它模板可能合用。

                所以,我覺得,SFINEA 的意義就是:

                編譯器在每個調用點上,只為當前需要實例化的類型尋找一個合適的模板進行展開,而不會為某一次實例化而展開所有可能合適的重載模板(函數(shù))。

                這是編譯器“智能”選擇模板的表現(xiàn)。普通函數(shù)重載則不一樣,無論是否被調用,或是無論調用點需要的是什么類型的重載,編譯器會將所有參與了重載的函數(shù)一個不落的全部編譯。如果對模板也采用同樣的方式,那么模板將受到巨大的局限而失去意義。

                有了 SFINEA ,當我們在寫模板代碼的時候,就不需要擔心這些模板在使用某些類型進行展開的時候會失敗,從而造成程序編譯錯誤,因為我們知道編譯器只會在能展開的情況展開它們,展開失敗的情況下,這些代碼并不會真正進入你的程序中。

                好了,在結束本文之前,我們再看看 SFINEA “知名”的一個例子:

                程序段2:

                template <typename T>
                class is_class {
                    typedef char one;
                    typedef struct {char a[2];} two;
            
                    template <typename C>
                    static one test(int C::*);
            
                    template <typename C>
                    static two test(...);
                public:
                    enum {value = sizeof(test<T>(0)) == sizeof(one)};
                };

                這是模板圣經(jīng)《C++ templates》中的一個例子(原程序可能不完全一樣),與程序段 1 不同的是,is_class<T>::value 是一個編譯期的 bool 值,而程序段 1 ,ture 或是 false 是在運行期才得到的結果。is_class<T>::value 這樣的“裝置”(device)經(jīng)常出現(xiàn)在模板編譯中,用于根據(jù)類型的某種特性(比如,是不是一個類?)來選擇不同的模板。boost 中的提供了很多類似的 device,再配合 boost::enable_if 來完成威力巨大的模板編程。

                可以說,SFINEA 幾乎是隨處可見的,不可或缺的重要“原則”。:)

                本文完。

             

             

             

            posted on 2009-11-14 14:01 唐風 閱讀(637) 評論(5)  編輯 收藏 引用 所屬分類: 語言技術

            評論

            # re: SFINEA in C++ 2009-11-14 15:11 OwnWaterloo
            代碼字體挺好看的。
            知名應用抄錯了:

            enum {value = sizeof(test<T>()) == sizeof(one)};

            這里要以一個0去調用test<T>:
            enum {value = sizeof(test<T>(0)) == sizeof(one)};
            如果T不是內(nèi)建類型,0就可以隱式轉換到T的成員的指針,否則匹配省略號版本。


            詳細見這里,包含一個更簡單的不使用SFINAE實現(xiàn)(代碼也更多)is_buildin的方法:
            http://www.shnenglu.com/Charlib/archive/2009/03/16/76799.html

              回復  更多評論
              

            # re: SFINEA in C++ 2009-11-14 18:00 唐風
            @OwnWaterloo
            謝謝指正!已經(jīng)修改了~
            憑記憶寫的,沒驗證就放上去了,不嚴謹啊不嚴謹啊,呵呵

            你的大作剛剛閱讀了,你學得比我透~
            我沒用C++做過什么實際的東西,一直浮在表面上。

            PS:
            關于代碼字體:
            直接用 Windows Live writer 加上插件 from visual studion 寫的,然后直接發(fā)布,感覺還不錯。在 cnblog 上正文的字體沒變化,不過 cppblog 上,有些字的大小變了,唉……  回復  更多評論
              

            # re: SFINEA in C++ 2009-11-15 02:33 OwnWaterloo
            現(xiàn)在和cnblogs的格式很相似了。
            Windows Live Wirter可以導入pdf,然后發(fā)布到blog么?

            或者Windows Live Writer在本地使用的什么格式? 可以diff(主要目的)么……

            我有個想法是用某種文本文件格式的代碼,比如html,latex,rst等,生成可以導入到Windows Live Writer的格式,再發(fā)布。
            文本格式的代碼可以diff……

              回復  更多評論
              

            # re: SFINEA in C++ 2009-11-15 10:31 唐風
            @OwnWaterloo
            WLW 支持類似“Rich text”的編輯器(標簽頁是“編輯”,只要cppblog上的CSS沒有另外設置,那么看到基本一致的效果)與一個純文件的編輯器(標簽頁是“源代碼”,可以獲取相應的html代碼),兩個是連動的。

            有時候我大面積更改已發(fā)布的文章中內(nèi)容的時候,也是先在編輯頁面修改,然后在源代碼頁面把html代碼拷出來,直接帖在cppblog(cnblogs)的編輯器里(純文本模式)。

            WLW 在本地還有什么其它格式我就不清楚了,不過我想應該想滿足diff的要求。
            不過直接導入PDF貌似不行……傳說word可以直接帖,保留格式,不過我沒用過,我很久沒用word了……哈哈

              回復  更多評論
              

            # re: SFINEA in C++ 2009-11-16 03:58 OwnWaterloo
            @唐風
            我試試 …… 謝謝~_~

              回復  更多評論
              

            俺来也俺去啦久久综合网| 久久亚洲精品国产亚洲老地址 | 久久狠狠高潮亚洲精品| 国产三级久久久精品麻豆三级 | 久久亚洲春色中文字幕久久久| 亚洲国产精品无码久久一线| 久久99精品久久久久久hb无码| 国产精品99久久不卡| 久久天天躁夜夜躁狠狠躁2022| 综合久久国产九一剧情麻豆| 亚洲国产精品久久66| 最新久久免费视频| 色综合久久中文色婷婷| 伊人久久大香线蕉亚洲五月天| 国产精品gz久久久| 精品久久久久久中文字幕人妻最新| 久久99国产一区二区三区| 色综合久久综合中文综合网| 久久精品国产清自在天天线| 精品久久人妻av中文字幕| 久久人人青草97香蕉| 理论片午午伦夜理片久久| 精品久久久久久国产| 中文字幕无码精品亚洲资源网久久| 国产综合成人久久大片91| 久久综合久久综合久久| 久久精品aⅴ无码中文字字幕不卡| 久久99热这里只有精品66| 久久影院亚洲一区| 91精品国产高清久久久久久国产嫩草| 久久久久国产精品熟女影院| 一本一道久久综合狠狠老| 久久久国产99久久国产一| 老司机午夜网站国内精品久久久久久久久| 精品永久久福利一区二区| 久久久av波多野一区二区| 77777亚洲午夜久久多喷| 无码AV波多野结衣久久| 久久国产免费直播| 午夜天堂av天堂久久久| 亚洲AV无码久久|