在C++中偵測內嵌型別的存在

　　動機(Motivation)　　假設一所大學的注冊系統提供了一個注冊函數：
　　template<class T>　　void Register(T person)　　{　　Register(person,typename T::person_tag());　　};　　而對於注冊者有以下幾種標識：
　　strUCt student_tag{};　　struct teacher_tag{};　　還有Register的幾個供內部使用的重載版本：
　　template<class T> void Register(T p,student_tag){...} //注冊學生　　template<class T> void Register(T p,teacher_tag){...} //注冊教師　　並規定學生類一定要在內部typedef student_tag person_tag ;教師類typedef teacher_tag person_tag ;這樣，當傳給起初的那個Register的對象為學生類對象時,typename T::person_tag()其實構造了一個student_tag對象，從而激發函數重載，調用Register內部版本的template<class T> void Register(T p,student_tag);版本。其他情況亦均有對應。這是泛型編程裡的常用手法，STL裡屢見不鮮。　　問題是，現在學校裡假如不止學生教師，還有工人，警衛等其它人員。假如他們不會在類內部typedef任何東西，則Register需要一種機制以確定T內部是否typedef了某個標識符(例如person_tag)。假如沒有，就默認處理。假如有，則再進行更具體的分類。　　實現(Implementation)　　這個問題可能有兩個實現途徑。　　第一，利用函數重載，具體如下：
　　typedef char (&yes_type)[1]; //sizeof(yes_type)==1　　typedef char (&no_type)[2];  //sizeof(no_type)==2　　以上的兩個typedef用於識別不同的重載函數。char (&)[1]表示對char[1]數組的引用，所以sizeof(char(&)[1])==sizeof(char[1])==1;注重圍繞&符號的一對圓括號，它們是必要的，假如沒有將會導致編譯錯誤，正如char* [1]將被解析為char*的數組，char& [1]將被解析為引用的數組，而後者是非法的。將&用圓括號包圍則改變了運算符的結合優先序，這將被解析為對char[1]數組的引用。
　　
　　

　　 更多內容請看C/C++技術專題專題，或
　　template<class T>　　struct does_sometypedef_exists　　{　　template<class U>　　static yes_type check(U,typename U::key_type*  =0); //請注重* 和=之間的空格，那是必要的,否則　　//編譯器會將它解析為operator*=操作符　　static no_type check(...);　　static T t;   //聲明　　static const bool value=sizeof(check(t))==sizeof(yes_type);　　};　　在我的VC7.0環境下，這樣測試是成功的：
　　struct A{};　　struct B　　{　　typedef int key_type;　　};　　int main()　　{　　std::cout<<does_sometypedef_exists<A>::value<<' '  //輸出0　　<<does_sometypedef_exists<B>::value<<' '  //輸出1　　<<std::endl;　　};　　下面我為你講解它的原理。　　當進行重載解析時，編譯器會首先嘗試具現化可以匹配的模板函數並將它們納入到有待進行重載解析的函數的候選單之列，在本例中，當typename T::key_type不存在時，check的第一個模板版本不能具現化(因為其第二個參數型別typename U::key_type*不存在)，所以只能匹配第二個版本。當typename T::key_type存在時，第一個模板函數可以具現化，且可以匹配(注重第二個參數為缺省參數)，所以無疑編譯器會匹配第一個版本，因為C++標准保證：只有當其它所有重載版本都不能匹配的時候含有任意型別參數列表的版本(在本例中那是no_type check(...))才會被匹配。
　　

　　
　　 更多內容請看C/C++技術專題專題，或 　　一個值得注重的地方是:check的第一個版本只能是模板函數，因為當編譯器推導型別的過程中發現該模板函數不能具現化時它就不去具現化它，而不是產生編譯錯誤(除非沒有其它可匹配的重載版本)。 <!-- frame contents --> <!-- /frame contents --> 因為編譯錯誤只有將代碼編譯的過程中才會產生，而既然模板沒有具現化，那麼該模板實際上並沒有經過編譯。　　然而，假如它不是模板函數，則隨著does_sometypedef_exists類的具現化。它也會被具現化，然而假如不存在T::key_type，那麼，該函數就成為非法。　　還有一個值得注重的地方是：does_sometypedef_exists內部的static T t;只是一個聲明，並不占用內存空間，更妙的是，因為是個聲明，所以編譯器根本不會對它初始化，所以它的默認構造函數就根本不會被執行，事實上，編譯器在這種情況下甚至不會去看一看它是否有可用的默認構造函數，它只需要型別信息就足夠了，不是麼？因此，即使由於某些原因T的默認構造函數被禁止(設為private)(例如，想讓T從堆上創建)，那麼以上的traits也不會通不過編譯。”但是，等等！”你仿佛意識到了問題：“check的參數是傳值的！這時假如T的拷貝構造函數是私有的將會發生什麼事情呢？”事實是，根本不用去擔心，在sizeof的世界裡，根本不會發生求值行為，編譯器只需要有關型別的信息。在編譯器內部蘊涵有一個巨大的型別推導系統。無論sizeof(...)裡的表達式多麼復雜，其型別都會最終在編譯期被正確推導出來。而對於sizeof(check(t))，編譯器有了函數的返回值型別信息就夠了，它並不會去執行函數的代碼，也不會做實際的傳參行為，所以拷貝構造也就無從發生。　　但這裡有一個十分怪異的問題(在我的VC7.0環境下存在)，假設我們增加一個新類：
　　struct C　　{　　template<class T>　　struct key_type{};  //請注重這是個模板類　　};　　按理說，這種情況下does_sometypedef_exists<C>::value應該為false，因為第一個重載版本的typename U::key_type*不能被推導為C::key_type* (C::key_type是個模板，它需要模板參數來具現化)，然而在我的VC7.0下它通過編譯了，並且結果為true!!(就是說重載解析為第一個check函數)假如我將check的第一個版本作一點小小的改動，像這樣：
　　template<class U>　　static yes_type check(U,typename U::key_type* = (typename U::key_type*)0);　　我僅僅加了一個轉換，編譯器就開始抱怨說使用模板類(它指的是C::key_type)需要模板參數了。我作了另外的種種測試(甚至我發現假如將10傳給它的第二個參數，編譯器會說不能將int轉換為C::key_typ*,是的，這是編譯錯誤的原文，這是否表示編譯器承認C::key_type*為一種型別呢？我不知道)。結論是只有當typename U::key_type*作為模板函數的參數型別時這種情況才會發生。
　　
　　

　　 更多內容請看C/C++技術專題專題，或 　　第二個實現是利用模板偏特化及默認模板參數的規則：
　　template<class T,class>　　struct check_helper　　{　　typedef T type;　　};　　template<class T,class =T>　　struct does_sometypedef_exists_1　　{　　static const bool value=false;　　};　　template<class T>　　struct does_sometypedef_exists_1<T,typename check_helper<T,typename T::key_type>::type>　　{                            //上面的兩個typename都是必要的。　　static const bool value=true;　　};　　這看起來很小巧，僅僅使用了模板偏特化。但是請耐心聽我解釋。　　假如typename X::key_type存在(假設X為任意類)，則does_sometypedef_exists_1<X>首先由模板推導將does_sometypedef_exists_1的模板參數T匹配為X，則其偏特化版本因而被推導為：
　　
　　 　　struct does_sometypedef_exists_1<X,typename check_helper<X,typename X::key_type>::type>　　而typename check_helper<X,typename X::key_type>::type根據check_helper的定義其實就是X,所以該偏特化版本其實被推導為：
　　struct does_sometypedef_exists_1<X,X>　　所以，假如你這樣測試：does_sometypedef_exists_1<X>::value，根據does_sometypedef_exists_1缺省定義(第二個模板參數默認為T)，你寫的相當於：does_sometypedef_exists_1<X,X>::value。　　而根據上面的推導，假如typename X::key_type存在，則does_sometypedef_exists_1的偏特化版本也存在且形式為:
　　  更多內容請看C/C++技術專題專題，或
　　struct does_sometypedef_exists_1<X,X>　　於是編譯器選擇匹配偏特化版本，其中的value值為true。　　而假如typename X::key_type不存在,則typename check_helper<X,typename X::key_type>::type也就隨之不存在，則does_sometypedef_exists_1的偏特化版本也就隨之不存在，於是編譯器會選擇使用缺省定義，其中value值為false。這正是我們所想要的結果。　　測試(Test)　　現在對我們的兩個實現版本測試一下吧，假設有一下幾個類：
　　struct A{};  //沒有key_type　　struct B{typedef int key_type;};  //typedef　　struct C{void key_type(void){}};  //key_type為成員函數　　struct D{static const bool key_type=false;}; //key_type為靜態常量數據成員　　const bool D::key_type;  //定義,D裡面的是聲明　　struct E{　　template<class>　　struct key_type{};  //key_type為模板類　　};　　template<class T>　　struct does_typedef_exists　　{　　typedef does_sometypedef_exists<T> impl_type;　　static const bool value=impl_type::value;　　};　　int main()　　{　　std::cout<<does_typedef_exists<A>::value<<' '　　<<does_typedef_exists<B>::value<<' '　　<<does_typedef_exists<C>::value<<' ' 
　　
　　

　　 更多內容請看C/C++技術專題專題，或
　　<<does_typedef_exists<D>::value<<' '　　<<does_typedef_exists<E>::value<<' '　　<<std::endl;　　return 0;　　};　　在我的VC7.0編譯平台上：　　假如使用第一種實現，這將輸出：0 1 0 0 1　　假如使用第二種實現，這將輸出：0 1 0 0 0　　很顯然，兩種實現對於struct E給出的結果不一樣。事實上，我們希望該traits對E這種情況給出的結果為1。從這一點講第一種實現在我的編譯器上已經神差鬼使的成功了，而第二種實現還沒有。不管怎樣，我們都必須試圖找到一種方法來實現它。這種方法不可以像實現一那樣依靠與編譯器的可能的“一時糊塗”，它應該是以C++標准的規則為依據的。Paul Mensonides提供了一種方法，然而在我的VC7.0上編譯不能通過。後面我會介紹它。　　改進(Improvement)　　第一種實現還可以做一點改進，像這樣：
　　template<class T>　　struct does_sometypedef_exists　　{　　template<class U>　　static yes_type check(typename U::key_type* ); 　　template<class U>　　static no_type check(...);　　static const bool value=sizeof(check<T>(0))==sizeof(yes_type);　　};　　這樣，去掉static T t，和check的第一個參數，會使代碼看上去更簡潔和更可靠一些。　　封裝(Encapsulation)
　　
　　
　　

　　 更多內容請看C/C++技術專題專題，或 　　現在我們的traits只能偵測typename T::key_type的存在性，我們需要一個擴充的機制，以讓我們能夠偵測任意名稱的內嵌型別的存在性。我們使用宏：
　　#define IMPLEMENT_TYPEDEF_EXISTS(id) 　　template<class T> 　　struct does_sometypedef_exists_##id 　　{ 　　private: 　　template<class U> 　　static yes_type check(typename U::id*); 　　template<class U> 　　static no_type check(...); 　　public: 　　static const bool value=sizeof(check<T>(0))==sizeof(yes_type); 　　};　　#define DOES_TYPEDEF_EXISTS(T,id) 　　does_sometypedef_exists_##id<T>　　經過這重封裝，當你要偵測某個名稱的內嵌型別如some_type時，你先在任何函數之外寫這樣的代碼：
　　IMPLEMENT_TYPEDEF_EXISTS(some_type)　　這將會擴展成一個名為does_sometypedef_exists_some_type的模板類，然後你這樣使用它:
　　DOES_TYPEDEF_EXISTS(X,some_type)::value;　　這將偵測類X中有沒有some_type。不將::value直接納入到宏中的原因是為了保留traits編程的風格。　　Paul Mensonides對內嵌template的偵測方法　　Paul Mensonides是Boost庫的preprocesser部分的設計者，那完全是一個宏的世界，也是Boost庫中的一個十分精巧的部分。我最初是在comp.lang.c++.moderated上看到它關於這個問題的解答的。
　　
　　
　　template<class> struct split;  //缺省聲明，因為不會被匹配所以不用定義 
　　
　　

　　 更多內容請看C/C++技術專題專題，或
　　//以下是偏特化　　template< template<class> class T, class T1 > //T為模板　　struct split< T<T1> > {　　struct type { };　　};　　template< template<class, class> class T, class T1, class T2 >　　struct split< T<T1, T2> > {　　struct type { };　　};　　// etc. :(，後面有支持更多模板參數的版本，從略　　template<class T> class has_template_key_type {　　private:　　template<class U>　　static yes_type check(　　typename split<　　typename U::template key_type<null_t> //匹配一個模板參數的內嵌模板　　>::type*　　);　　template<class U>　　static yes_type check(　　typename split< 
　　

　　 更多內容請看C/C++技術專題專題，或
　　typename U::template key_type<null_t, null_t>  //匹配兩個模板參數的內嵌模板　　>::type*　　);
　　
　　// etc. :( 後面有支持更多模板參數的版本，從略　　template<class U> static no_type check(...);　　public:　　static const bool value　　= sizeof(check<T>(0)) == sizeof(yes_type);　　};　　template<class T, bool V = has_template_key_type<T>::value> //假如有內嵌模板則會轉入下面的偏特化　　class has_key_type {　　private:　　template<class U> static yes_type check(typename U::key_type*);　　template<class U> static no_type check(...);　　public:　　static const bool value　　= sizeof(check<T>(0)) == sizeof(yes_type);  //假如沒有內嵌模板則會這樣判定　　};　　template<class T> struct has_key_type<T, true> { //假如有內嵌模板　　static const bool value = false;           //則將value設為false　　};　　Paul Mensonides說它能夠工作，我也覺得根據標准它也該能夠工作，但事實是在我的VC7.0上編譯器有一大堆抱怨。我試了其它各種方法，結果總是類似的編譯錯誤將我擋住。我希望它在你的編譯器上能夠工作。　　這裡的原理是這樣的，假如類型X有內嵌模板型別定義key_type，則has_template_key_type中的返回yes_type的那些成員函數總有一個能夠與它匹配，而其它則不會被具現化(VC7.0仿佛總試圖將其它的也具現化了，結果它總會抱怨說模板參數太少或太多)。　　然而Paul Mensonides的這個解決方案還有個問題：假如那個內嵌的模板類的定義像如下這個樣子：
　　
　　 　　template<int>　　struct key_type{};　　則將沒有任何一個返回yes_type的重載版本能和它匹配，看看split類的定義吧，它的template template模板參數的形式是template<class[ ,class ,...]> class T，而上面的key_type的形式為template<int> class key_type,它們無法匹配，假如試圖再加入一個能與其匹配的split偏特化版本:
　　template<template<int>class T,int T1> struct split<T<T1>  >{...};　　這也是不實際的。因為int和class可能有無窮多種組合。假如key_type再變成template<int,class> class key_type呢？假如...，總之，如你所見，以int作為模板參數的加入使事情有了無限多種可能。split將窮於應付。　　結論(Conclusion)　　對於最後我提出的問題，仿佛沒有一個好的解決方案。所以只能放棄這種內嵌template的可能，假定情況是單純的。對於後者，這種技術有教好的表現。
　　
　　
　　
　　

　　 更多內容請看C/C++技術專題專題，或