青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

cexer

cexer
posts - 12, comments - 334, trackbacks - 0, articles - 0
  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

轉(zhuǎn)帖請注明出處 http://m.shnenglu.com/cexer/archive/2008/07/06/55484.html

  VC當(dāng)中有一個鮮為人知的關(guān)鍵字,除了微軟自己的代碼,我從未在任何地方看到有人用過它。雖然它的功能很強大,不過除非設(shè)計上的問題或是一些無法排除的困難,否則幾乎從不會需要用到它的功能。但是有時候,它確實能作為一個最簡單的解決方案而讓某些設(shè)計過程事半功倍。

  借用 CCTV10《走近科學(xué)》的語氣:那么這個神秘的關(guān)鍵關(guān)鍵字到底是什么呢?它又實現(xiàn)了什么神奇的功能呢?帶著這一連串的疑問,讓我們先來看一個具體的例子。

  我在自己曾經(jīng)寫的一個GUI框架當(dāng)中,為了實現(xiàn)消息與處理函數(shù)自動映射的,就需要求助于這種功能。比如說有一個窗口類,它包含若干消息處理函數(shù)和一個消息與處理函數(shù)的映射 map:(請無視當(dāng)中的 show() 和 create() 函數(shù),與主題無關(guān))

    class Window
{
typedef UINT _Message;
typedef LRESULT (Window::*_Handler)(_Message);

map<_Message,_Handler> m_handlerMap;

public:
bool show();
bool create();

public:
LRESULT onEvent( WindowEvent<WM_CREATE> );
LRESULT onEvent( WindowEvent<WM_DESTROY> );
};

  
  我需要利用模板元編程 從 0 到 WM_USER  進行循環(huán)檢測,檢測 Window 類是否存在該消息對應(yīng)的處理函數(shù)。如果消息對應(yīng)的處理函數(shù)存在,那么就將消息與函數(shù)的映射放進 m_handlerMap 當(dāng)中。比如說消息 WM_CREATE,我檢測類 Window是否存在 LRESULT onEvent( WindowEvent<WM_CREATE> ) 成員函數(shù),在上例代碼中是存在的,于是我將這樣一個映射放進m_handlerMap:(真正實現(xiàn)的時候,還要考慮函數(shù)的類型。不同類型的函數(shù),是不能直接裝進 map 當(dāng)中的。不過在這里請無視例子當(dāng)中涉及的所有類型轉(zhuǎn)換,與主題無關(guān))

    pair<WM_CREATE,&Window::onEvent>


  這樣就達(dá)到了消息自動映射的目的。而不用像MFC一樣手寫宏去映射。(最后通過努力的確達(dá)到了我的目的,我的GUI框架能夠進行自動消息映射了,然而可以預(yù)見,由于幾千個(0-WM_USER)循環(huán),編譯期的速度受到極大影響。所以最終我還是拋棄了這種自動映射實現(xiàn),而采用了更高效神奇的方法,這是后話也與本主題無關(guān)就先不提)。

  要實現(xiàn)以上的自動映射功能就引出了這樣一個難題:如何編譯期檢測類的某特定名字的成員是否存在。

  功能不負(fù)有心人,經(jīng)過爬山涉水翻山越嶺,我終于在 MSDN 一個偏遠(yuǎn)角落里找著了傳說當(dāng)中那個神秘的關(guān)鍵字:__if_exists(其實還有一個 __if_not_exists)。MSDN 當(dāng)中這樣說明:__if_exists (__if_not_exists)允許你針對某符號的存在與否條件性地執(zhí)行語句。使用語法:(注意檢測的是“存在性”,而不是值)

    __if_exists ( /*你要檢測存在性的函數(shù)或變量的名字*/ ) { 
 //做些有用的事
}


  MSDN當(dāng)中的示例代碼如下:
    // the__if_exists_statement.cpp
// compile with: /EHsc
#include <iostream>

template<typename T>
class X : public T {
public:
void Dump() {
std::cout << "In X<T>::Dump()" << std::endl;

__if_exists(T::Dump) {
T::Dump();
}

__if_not_exists(T::Dump) {
std::cout << "T::Dump does not exist" << std::endl;
}
}
};

class A {
public:
void Dump() {
std::cout << "In A::Dump()" << std::endl;
}
};

class B {};

bool g_bFlag = true;

class C {
public:
void f(int);
void f(double);
};

int main() {
X<A> x1;
X<B> x2;

x1.Dump();
x2.Dump();

__if_exists(::g_bFlag) {
std::cout << "g_bFlag = " << g_bFlag << std::endl;
}

__if_exists(C::f) {
std::cout << "C::f exists" << std::endl;
}

return 0;
}


  以上代碼的輸出如下:(未測試,此輸出為MSDN的說明文檔當(dāng)中的)

    In X<T>::Dump()
In A::Dump()
In X<T>::Dump()
T::Dump does not exist
g_bFlag = 1
C::f exists


  大概很少人見過這個關(guān)鍵字吧。雖然它們的功能與我的需求是如此的接近,但是面對如此強憾的關(guān)鍵字,我還是只能搖頭嘆息。我傷心地在文檔里看到說明,__if_exists(__if_not_exists)關(guān)鍵字用于函數(shù)的時候,只能根據(jù)函數(shù)名字進行檢測,而會忽略對參數(shù)列表的檢測,因此沒有對重載函數(shù)的分辨能力,而正是我需要的。比如類 Window 有一個函數(shù):

    LRESULT Window::onEvent( WindowEvent<WM_DESTROY> )
{
//做些有用的事
}


  我用以下代碼來檢測 WM_CREATE 消息是否存在處理函數(shù):

    __if_exists(Window::onEvent)
  {
      //添加消息映射
   }


  即使 Window 類當(dāng)中不存在 LRESULT onEvent ( WindowEvent<WM_CREATE> ),以上測試也能通過。這是因為 __if_exists 關(guān)鍵字是不管函數(shù)重載的,如果存在一個 onEvent ,那么所有的檢測都能通過。這不是我想要的。我需要比 __if_exists 更強憾的檢測功能,強憾到能夠針對不同參數(shù)列表的同名函數(shù)(重載函數(shù))做出正確的存在性測試。

  于是我繼續(xù)翻山越嶺地尋找,從 CSDN 到 MSDN,從 SourceForge 到 CodeProject。要相信那句老話:“有心人天不負(fù)”。最后我在 CodeProject 上面看到一篇讓我醍醐灌頂?shù)奈恼拢?/p>

  Interface Detection by Alexandre Courpron

  這篇文章從原理到實現(xiàn),很詳細(xì)地說明地一種編譯期檢測技術(shù),先說明一下,由于VC7.1數(shù)千個bug當(dāng)中的一個,以下技術(shù)不能在VC++7.1或更低版本上使用。具體的實現(xiàn)在那篇文章當(dāng)中說得很詳盡了,還是在這兒贅述一下。

  Alexandre Courpron的實現(xiàn)方式基于C++的這樣一個規(guī)則:Substitution Failure Is Not An Error(簡稱SFINAE)。它的含義我也理解得比較含糊,不過它作用于重載函數(shù)的時候,可以這樣理解:對于一個函數(shù)調(diào)用,在匹配函數(shù)的過程當(dāng)中,如果最終能夠有一個函數(shù)匹配成功,那么對其余函數(shù)的匹配如果失敗,編譯器也不會視為錯誤。聽起來有些麻煩,看Alexandre Courpron給出的例子:

    struct Test 
{
typedef int Type;
};

template < typename T >
void f(typename T::Type) {} // definition #1

template<typename T>
void f(T){} // definition #2

f<Test>(10); //call #1

f<int>(10); //call #2

  
  對于 call#1 編譯器直接匹配 definition#1 成功。對于 call#2,編譯器先用 definition#1 匹配 如下:

    void f( typename int::Type ) {}


  這顯然是不正確的。不過編譯器并沒有編譯失敗報告錯誤,因為下面的 definition#2 匹配成功,根據(jù) SFINAE的 規(guī)則,編譯器有權(quán)保持沉默 。

  雖然是個小小的規(guī)則,在平時幾乎不會注意它。然而在這兒,我們卻可以利用它實現(xiàn)編譯期檢測的強大功能了,一個最簡單的示例:

    #include <iostream>
using namespace std;
//
struct TestClass
{
void testFun();
};

struct Exists { char x;};
struct NotExists { char x[2]; };

template <void (TestClass::*)()>
struct Param ;

template <class T>
Exists isExists( Param<&T::testFun>* );

template <class T>
NotExists isExists( ... );
//
int main()
{
cout<<sizeof(isExists<TestClass>(0))<<endl;
}


  上面的代碼會輸出 1。說明一下檢測的過程:

  1. 編譯器遇到 isExists<TestClass>(0) 這一句,會去匹配 isExists 的兩個重載函數(shù)。不定長的參數(shù)優(yōu)先級更低,因此先匹配第一個函數(shù)。
  2. 第一個函數(shù)參數(shù)類型為 Param<&T::testFun>*,在這里是 Param<&TestClass::testFun>,編譯器在匹配這個參數(shù)類型的時候會嘗試實例化模板類 Param。
  3. 編譯器嘗試用 &TestClass::testFun 去實例化 Param,因為 TestClass 確實存在一個 void (TestClass::*)() 類型,且名為 testFun 的成員函數(shù)。所以 Param 的實例化成功,因此參數(shù)匹配成功。
  4. 匹配第一個函數(shù)成功。編譯器決定 isExists<TestClass>(0) 這一句調(diào)用就是調(diào)用的第一個函數(shù)。
  5. 因為第一個函數(shù)返回的類型為 Exists,用 sizeof 取大小就是 1。

  如果是我們把 TestClass 的定義修改為:(僅把函數(shù)的參數(shù)類型改為 int )

    struct TestClass
{
void testFun(int);
};


  這一次代碼會輸出 2。因為在第3步的時候,由于 TestClass 沒有類型為 void (TestClass::*)(),且名為 testFun 的函數(shù),所以實例化 Param 會失敗,因此匹配第一個函數(shù)失敗。然后編譯器去匹配第二個函數(shù)。因為其參數(shù)類型是任意的,自然會匹配成功。結(jié)果會輸出 2。

  當(dāng)然這只是個最簡單的示例,通過模板包裝類。可以實現(xiàn)更靈活更強大的功能。比如回到那個自動消息映射的例子,用以下代碼就能夠?qū)崿F(xiàn)了:

//c++std
#include <iostream>
using namespace std;



//windows
#include <windows.h>


//detector
template<typename TWindow,UINT t_msg>
struct MessageHandlerDetector
{
typedef WindowEvent<t_msg> _Event;

struct Exists {char x;};
struct NotExists {char x[2];};

template<LRESULT (TWindow::*)(_Event)>
struct Param;

template<typename T>
static Exists detect( Param<&T::onEvent>* );

template<typename T>
static NotExists detect( ... );

public:
enum{isExists=sizeof(detect<TWindow>(0))==sizeof(Exists)};
};

//test classes
struct Window
{
LRESULT onEvent( WindowEvent<WM_CREATE> );
};

struct Button
{
LRESULT onEvent( WindowEvent<WM_DESTROY> );
};

//main
int main()
{
cout<<MessageHandlerDetector<Window,WM_CREATE>::isExists<<endl;
cout<<MessageHandlerDetector<Window,WM_DESTROY>::isExists<<endl;
cout<<MessageHandlerDetector<Button,WM_CREATE>::isExists<<endl;
cout<<MessageHandlerDetector<Button,WM_DESTROY>::isExists<<endl;

return 0;
}



  以上代碼會輸出:

    1
0
0
1


  以上的示例代碼再加上模板元編程,可以很輕易地實現(xiàn)消息的自動映射,具體實現(xiàn)這個已不在本貼的討論范圍并且這種自動映射的實現(xiàn),太過復(fù)雜,在編譯期沒有效率,且不夠靈活。不過在消息映射機制上來說,已稱得上是一種革命性的嘗試。

  在說完了這所有一切之后,再告訴你一個我最近才知道的秘密(不準(zhǔn)笑我孤陋寡聞):其實 boost 庫當(dāng)中已有相關(guān)功能的 MPL  工具存在,叫做 has_xxx。

  源文件:<boost\mpl\has_xxx.hpp>

  文檔:http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/has-xxx-trait-def.html

Feedback

# re: C++編譯期函數(shù)/變量檢測技術(shù),超越VC的某某關(guān)鍵字  回復(fù)  更多評論   

2008-07-06 23:54 by Bill Gates
不就是traits嗎

# re: C++編譯期函數(shù)/變量檢測技術(shù),超越VC的某某關(guān)鍵字  回復(fù)  更多評論   

2008-07-06 23:56 by cexer
不是。并不是涉及模板就能用traits來說事的。

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2008-07-08 18:29 by 周星星
好方法呀,俺也一直在尋找 __if_exists 的替代方法(用標(biāo)準(zhǔn)C++語法)

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2008-07-08 19:50 by cexer
你可以看看,boost有更好的實現(xiàn)。

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2008-07-10 23:13 by 夢在天涯
沒用過,有難度,長見識!

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2008-08-19 12:47 by 螞蟻終結(jié)者
不錯,有點意思。

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2009-09-24 11:20 by pipilu
問一下怎么編譯器比較兩個常數(shù)來設(shè)置編譯呢

#define AAA 12

// 如果 AAA > 12 則編譯下面內(nèi)容
bool bUse = 134;

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2012-06-01 01:09 by 春秋十二月
不錯 受益了

# re: C++編譯期函數(shù)/變量檢測技術(shù),仿真VC關(guān)鍵字__if_exists  回復(fù)  更多評論   

2013-05-30 14:01 by zirandeai
我覺得這只是語法糖,增加了復(fù)雜度,卻并未讓人看到實質(zhì)性的好處
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美激情一区二区| 欧美精品一区二区三区久久久竹菊| 蜜桃久久av一区| 99精品欧美| 久久综合亚洲社区| 国产在线视频欧美一区二区三区| 艳女tv在线观看国产一区| 久久久另类综合| 亚洲在线网站| 国产精品黄色在线观看| 亚洲精品久久视频| 亚洲高清免费视频| 久久伊人精品天天| 韩国三级电影一区二区| 久久本道综合色狠狠五月| 一本色道久久88精品综合| 欧美日韩国产精品一卡| 一区二区三区四区五区在线| 亚洲日本成人网| 欧美日韩一区在线观看视频| 中文av字幕一区| 一本色道久久综合亚洲精品婷婷| 欧美激情精品久久久久久久变态| 亚洲日本电影在线| 亚洲国产成人在线| 欧美男人的天堂| 亚洲欧美激情视频在线观看一区二区三区 | 欧美黄色一级视频| 免费不卡在线观看av| 日韩一区二区免费高清| 亚洲最黄网站| 国产午夜精品视频免费不卡69堂| 久久精品水蜜桃av综合天堂| 久久久久久夜精品精品免费| 亚洲国产小视频在线观看| 亚洲经典在线| 国产精品久久| 久久久久免费观看| 欧美成年人视频网站| 在线性视频日韩欧美| 亚洲人在线视频| 亚洲免费激情| 国产精品爽爽爽| 免费一级欧美片在线播放| 欧美精品一区视频| 久久er精品视频| 久久综合一区二区| 亚洲欧洲av一区二区| 久久久久国产精品一区三寸 | 久久久水蜜桃| 欧美国产日韩视频| 欧美一级久久久| 免费一区二区三区| 午夜日韩av| 欧美高清视频一二三区| 午夜精品视频在线| 麻豆91精品| 午夜亚洲激情| 欧美国产极速在线| 久久久久久亚洲精品杨幂换脸 | 欧美xart系列在线观看| 欧美人在线观看| 久久中文字幕一区| 国产精品成av人在线视午夜片| 久久一二三国产| 国产精品视频一区二区三区| 亚洲电影欧美电影有声小说| 国产欧美日韩视频在线观看| 亚洲精品日日夜夜| 尤物yw午夜国产精品视频明星| 一本色道久久综合一区| 亚洲人成在线播放| 久久精品国产欧美激情| 亚洲免费在线| 欧美精品一区三区在线观看| 老司机一区二区三区| 国产乱码精品一区二区三区忘忧草 | 亚洲三级电影全部在线观看高清| 亚洲欧美中文日韩v在线观看| 亚洲日本欧美天堂| 久久久99爱| 久久精品日产第一区二区三区| 欧美日韩中文另类| 最新国产拍偷乱拍精品 | 久久精品免费| 国产精品日产欧美久久久久| 日韩亚洲精品在线| 99国产精品视频免费观看一公开| 久久久久欧美精品| 久久青草欧美一区二区三区| 国产欧美日韩激情| 亚洲在线播放电影| 亚洲网站在线| 欧美日韩亚洲一区三区 | 99国产精品久久久久久久久久 | 欧美视频免费在线| 亚洲欧美日韩综合一区| 久久久久国色av免费看影院| 夜夜嗨av一区二区三区四区| 亚洲免费视频网站| 91久久久久久久久| 亚洲免费视频在线观看| 亚洲片区在线| 欧美在线观看你懂的| 亚洲免费大片| 久久精品91久久久久久再现| 亚洲天堂av综合网| 久久夜色精品亚洲噜噜国产mv| 亚洲一区二区成人| 蜜桃伊人久久| 久久婷婷蜜乳一本欲蜜臀| 欧美日韩亚洲综合| 蜜桃精品久久久久久久免费影院| 欧美视频一区二区三区| 欧美xx视频| 国内精品久久久久影院优| 日韩一级裸体免费视频| 亚洲国产欧美国产综合一区| 亚洲一区激情| 亚洲一区二区三区四区五区黄 | 久久综合国产精品台湾中文娱乐网| 欧美人妖在线观看| 欧美二区乱c少妇| 黄色一区二区在线观看| 亚洲欧美视频| 午夜精彩视频在线观看不卡| 欧美伦理91i| 亚洲高清不卡av| 在线观看亚洲视频啊啊啊啊| 亚洲在线视频一区| 午夜一区在线| 欧美日韩情趣电影| 亚洲伦理网站| 一区二区三区久久网| 欧美精品在线极品| 亚洲日本在线观看| av成人国产| 欧美午夜精品| 亚洲影院在线| 欧美专区中文字幕| 国产日韩在线视频| 欧美一区三区三区高中清蜜桃| 亚洲欧美一区二区在线观看| 国产精品99一区| 亚洲一区二区在线播放| 欧美一级片久久久久久久| 国产欧美精品一区二区色综合| 亚洲在线视频网站| 麻豆免费精品视频| 亚洲精品在线观看免费| 欧美激情视频在线播放| 亚洲精品中文字幕女同| 亚洲一区二区三区在线播放| 午夜影院日韩| 久久久精品日韩欧美| 亚洲国产精品成人综合| 欧美高清不卡| 一区二区三区精品| 久久精品国产一区二区三| 亚洲福利国产| 欧美三级资源在线| 欧美一级专区| 亚洲福利在线视频| 亚洲欧美不卡| 好吊日精品视频| 欧美精品免费观看二区| 亚洲——在线| 欧美成人免费网| 一区二区三区久久网| 国产精品久久久999| 欧美亚洲一区二区三区| 久久午夜羞羞影院免费观看| 韩国一区二区三区美女美女秀| 欧美激情第五页| 亚洲精品影院在线观看| 国产综合久久久久久鬼色| 你懂的视频一区二区| 日韩视频免费在线观看| 先锋影音久久| 日韩亚洲国产精品| 国产精品视频网| 久久男女视频| 亚洲美女视频| 亚洲第一搞黄网站| 亚洲无线视频| 一区国产精品| 国产日韩欧美成人| 老司机免费视频久久| 91久久精品国产91性色tv| 亚洲一区二区三区乱码aⅴ| 91久久综合亚洲鲁鲁五月天| 国产精品黄色| 欧美~级网站不卡| 欧美岛国在线观看| 亚洲一区3d动漫同人无遮挡| 狠狠做深爱婷婷久久综合一区 | 久久精品30| 一区二区激情| av不卡免费看| 亚洲第一黄色|