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

兔子的技術博客

兔子

   :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
  202 Posts :: 0 Stories :: 43 Comments :: 0 Trackbacks

留言簿(10)

最新評論

閱讀排行榜

評論排行榜

撰文:Don Clugston
引子


標準C++中沒有真正的面向對象的函數指針。這一點對C++來說是不幸的,因為面向對象的指針(也叫做"閉包(closure)"或"委托(delegate)")在一些語言中已經證明了它寶貴的價值。在Delphi (Object Pascal)中,面向對象的函數指針是Borland可視化組建庫(VCL,Visual Component Library)的基礎。而在目前,C#使"委托"的概念日趨流行,這也正顯示出C#這種語言的成功。在很多應用程序中,"委托"簡化了松耦合對象的設計模式[GoF]。這種特性無疑在標準C++中也會產生很大的作用。


很遺憾,C++中沒有"委托",它只提供了成員函數指針(member function pointers)。很多程序員從沒有用過函數指針,這是有特定的原因的。因為函數指針自身有很多奇怪的語法規(guī)則(比如"->*"和".*"操作符),而且很難找到它們的準確含義,并且你會找到更好的辦法以避免使用函數指針。更具有諷刺意味的是:事實上,編譯器的編寫者如果實現"委托"的話會比他費勁地實現成員函數指針要容易地多!


在這篇文章中,我要揭開成員函數指針那"神秘的蓋子"。在扼要地重述成員函數指針的語法和特性之后,我會向讀者解釋成員函數指針在一些常用的編譯器中是怎樣實現的,然后我會向大家展示編譯器怎樣有效地實現"委托"。最后我會利用這些精深的知識向你展示在C++編譯器上實現優(yōu)化而可靠的"委托"的技術。比如,在Visual C++(6.0, .NET, and .NET 2003)中對單一目標委托(single-target delegate)的調用,編譯器僅僅生成兩行匯編代碼!


函數指針


下面我們復習一下函數指針。在C和C++語言中,一個命名為my_func_ptr的函數指針指向一個以一個int和一個char*為參數的函數,這個函數返回一個浮點值,聲明如下:


float (*my_func_ptr)(int, char *);

//為了便于理解,我強烈推薦你使用typedef關鍵字。

//如果不這樣的話,當函數指針作為一個函數的參數傳遞的時候,

// 程序會變得晦澀難懂。

// 這樣的話,聲明應如下所示:

typedef float (*MyFuncPtrType)(int, char *);

MyFuncPtrType my_func_ptr;


應注意,對每一個函數的參數組合,函數指針的類型應該是不同的。在Microsoft Visual C++(以下稱MSVC)中,對三種不同的調用方式有不同的類型:__cdecl, __stdcall, 和__fastcall。如果你的函數指針指向一個型如float some_func(int, char *)的函數,這樣做就可以了:


my_func_ptr = some_func;


當你想調用它所指向的函數時,你可以這樣寫:


(*my_func_ptr)(7, "Arbitrary String");


你可以將一種類型的函數指針轉換成另一種函數指針類型,但你不可以將一個函數指針指向一個void *型的數據指針。其他的轉換操作就不用詳敘了。一個函數指針可以被設置為0來表明它是一個空指針。所有的比較運算符(==, !=, <, >, <=, >=)都可以使用,可以使用"==0"或通過一個顯式的布爾轉換來測試指針是否為空(null)。


在C語言中,函數指針通常用來像qsort一樣將函數作為參數,或者作為Windows系統(tǒng)函數的回調函數等等。函數指針還有很多其他的應用。函數指針的實現很簡單:它們只是"代碼指針(code pointer)",它們體現在匯編語言中是用來保存子程序代碼的首地址。而這種函數指針的存在只是為了保證使用了正確的調用規(guī)范。


成員函數指針


在C++程序中,很多函數是成員函數,即這些函數是某個類中的一部分。你不可以像一個普通的函數指針那樣指向一個成員函數,正確的做法應該是,你必須使用一個成員函數指針。一個成員函數的指針指向類中的一個成員函數,并和以前有相同的參數,聲明如下:


float (SomeClass::*my_memfunc_ptr)(int, char *);

//對于使用const關鍵字修飾的成員函數,聲明如下:

float (SomeClass::*my_const_memfunc_ptr)(int, char *) const;


注意使用了特殊的運算符(::*),而"SomeClass"是聲明中的一部分。成員函數指針有一個可怕的限制:它們只能指向一個特定的類中的成員函數。對每一種參數的組合,需要有不同的成員函數指針類型,而且對每種使用const修飾的函數和不同類中的函數,也要有不同的函數指針類型。在MSVC中,對下面這四種調用方式都有一種不同的調用類型:__cdecl, __stdcall, __fastcall, 和 __thiscall。(__thiscall是缺省的方式,有趣的是,在任何官方文檔中從沒有對__thiscall關鍵字的詳細描述,但是它經常在錯誤信息中出現。如果你顯式地使用它,你會看到"它被保留作為以后使用(it is reserved for future use)"的錯誤提示。)如果你使用了成員函數指針,你最好使用typedef以防止混淆。


將函數指針指向型如float SomeClass::some_member_func(int, char *)的函數,你可以這樣寫:


my_memfunc_ptr = &SomeClass::some_member_func;


很多編譯器(比如MSVC)會讓你去掉"&",而其他一些編譯器(比如GNU G++)則需要添加"&",所以在手寫程序的時候我建議把它添上。若要調用成員函數指針,你需要先建立SomeClass的一個實例,并使用特殊操作符"->*",這個操作符的優(yōu)先級較低,你需要將其適當地放入圓括號內。


SomeClass *x = new SomeClass;

(x->*my_memfunc_ptr)(6, "Another Arbitrary Parameter");

//如果類在棧上,你也可以使用".*"運算符。

SomeClass y;

(y.*my_memfunc_ptr)(15, "Different parameters this time");


不要怪我使用如此奇怪的語法——看起來C++的設計者對標點符號有著由衷的感情!C++相對于C增加了三種特殊運算符來支持成員指針。"::*"用于指針的聲明,而"->*"和".*"用來調用指針指向的函數。這樣看起來對一個語言模糊而又很少使用的部分的過分關注是多余的。(你當然可以重載"->*"這些運算符,但這不是本文所要涉及的范圍。)


一個成員函數指針可以被設置成0,并可以使用"=="和"!="比較運算符,但只能限定在同一個類中的成員函數的指針之間進行這樣的比較。任何成員函數指針都可以和0做比較以判斷它是否為空。與函數指針不同,不等運算符(<, >, <=, >=)對成員函數指針是不可用的。


成員函數指針的怪異之處


成員函數指針有時表現得很奇怪。首先,你不可以用一個成員函數指針指向一個靜態(tài)成員函數,你必須使用普通的函數指針才行(在這里"成員函數指針"會產生誤解,它實際上應該是"非靜態(tài)成員函數指針"才對)。其次,當使用類的繼承時,會出現一些比較奇怪的情況。比如,下面的代碼在MSVC下會編譯成功(注意代碼注釋):


#include "stdio.h"

class SomeClass {

public:

virtual void some_member_func(int x, char *p) {

printf("In SomeClass"); };

};


class DerivedClass : public SomeClass {

public:

// 如果你把下一行的注釋銷掉,帶有 line (*)的那一行會出現錯誤

// virtual void some_member_func(int x, char *p) { printf("In DerivedClass"); };

};


int main() {

//聲明SomeClass的成員函數指針

typedef void (SomeClass::*SomeClassMFP)(int, char *);

SomeClassMFP my_memfunc_ptr;

my_memfunc_ptr = &DerivedClass::some_member_func; // ---- line (*)

return 0;

}


奇怪的是,&DerivedClass::some_member_func是一個SomeClass類的成員函數指針,而不是DerivedClass類的成員函數指針!(一些編譯器稍微有些不同:比如,對于Digital Mars C++,在上面的例子中,&DerivedClass::some_member_func會被認為沒有定義。)但是,如果在DerivedClass類中重寫(override)了some_member_func函數,代碼就無法通過編譯,因為現在的&DerivedClass::some_member_func已成為DerivedClass類中的成員函數指針!


成員函數指針之間的類型轉換是一個討論起來非常模糊的話題。在C++的標準化的過程中,在涉及繼承的類的成員函數指針時,對于將成員函數指針轉化為基類的成員函數指針還是轉化為子類成員函數指針的問題和是否可以將一個類的成員函數指針轉化為另一個不相關的類的成員函數指針的問題,人們曾有過很激烈的爭論。然而不幸的是,在標準委員會做出決定之前,不同的編譯器生產商已經根據自己對這些問題的不同的回答實現了自己的編譯器。根據標準(第5.2.10/9節(jié)),你可以使用reinterpret_cast在一個成員函數指針中保存一個與本來的類不相關的類的成員函數。有關成員函數指針轉換的問題的最終結果也沒有確定下來。你現在所能做的還是像以前那樣——將成員函數指針轉化為本類的成員函數的指針。在文章的后面我會繼續(xù)討論這個問題,因為這正是各個編譯器對這樣一個標準沒有達成共識的一個話題。


在一些編譯器中,在基類和子類的成員函數指針之間的轉換時常有怪事發(fā)生。當涉及到多重繼承時,使用reinterpret_cast將子類轉換成基類時,對某一特定編譯器來說有可能通過編譯,而也有可能通不過編譯,這取決于在子類的基類列表中的基類的順序!下面就是一個例子:


class Derived: public Base1, public Base2 // 情況 (a)

class Derived2: public Base2, public Base1 // 情況 (b)

typedef void (Derived::* Derived_mfp)();

typedef void (Derived2::* Derived2_mfp)();

typedef void (Base1::* Base1mfp) ();

typedef void (Base2::* Base2mfp) ();

Derived_mfp x;


對于情況(a),static_cast<Base1mfp>(x)是合法的,而static_cast<Base2mfp>(x)則是錯誤的。然而情況(b)卻與之相反。你只可以安全地將子類的成員函數指針轉化為第一個基類的成員函數指針!如果你要實驗一下,MSVC會發(fā)出C4407號警告,而Digital Mars C++會出現編譯錯誤。如果用reinterpret_cast代替static_cast,這兩個編譯器都會發(fā)生錯誤,但是兩種編譯器對此有著不同的原因。但是一些編譯器對此細節(jié)置之不理,大家可要小心了!


標準C++中另一條有趣的規(guī)則是:你可以在類定義之前聲明它的成員函數指針。這對一些編譯器會有一些無法預料的副作用。我待會討論這個問題,現在你只要知道要盡可能得避免這種情況就是了。


需要值得注意的是,就像成員函數指針,標準C++中同樣提供了成員數據指針(member data pointer)。它們具有相同的操作符,而且有一些實現原則也是相同的。它們用在stl::stable_sort的一些實現方案中,而對此很多其他的應用我就不再提及了。


成員函數指針的使用


現在你可能會覺得成員函數指針是有些奇異。但它可以用來做什么呢?對此我在網上做了非常廣泛的調查。最后我總結出使用成員函數指針的兩點原因:

 

用來做例子給C++初學者看,幫助它們學習語法;或者


為了實現"委托(delegate)"!


成員函數指針在STL和Boost庫的單行函數適配器(one-line function adaptor)中的使用是微不足道的,而且允許你將成員函數和標準算法混合使用。但是它們最重要的應用是在不同類型的應用程序框架中,比如它們形成了MFC消息系統(tǒng)的核心。


當你使用MFC的消息映射宏(比如ON_COMMAND)時,你會組裝一個包含消息ID和成員函數指針(型如:CCmdTarget::*成員函數指針)的序列。這是MFC類必須繼承CCmdTarget才可以處理消息的原因之一。但是,各種不同的消息處理函數具有不同的參數列表(比如OnDraw處理函數的第一個參數的類型為CDC *),所以序列中必須包含各種不同類型的成員函數指針。MFC是怎樣做到這一點的呢?MFC利用了一個可怕的編譯器漏洞(hack),它將所有可能出現的成員函數指針放到一個龐大的聯(lián)合(union)中,從而避免了通常需要進行的C++類型匹配檢查。(看一下afximpl.h和cmdtarg.cpp中名為MessageMapFunctions的union,你就會發(fā)現這一恐怖的事實。)因為MFC有如此重要的一部分代碼,所以事實是,所有的編譯器都為這個漏洞開了綠燈。(但是,在后面我們會看到,如果一些類用到了多重繼承,這個漏洞在MSVC中就不會起作用,這正是在使用MFC時只能必須使用單一繼承的原因。)


在boost::function中有類似的漏洞(但不是太嚴重)。看起來如果你想做任何有關成員函數指針的比較有趣的事,你就必須做好與這個語言的漏洞進行挑戰(zhàn)的準備。要是你想否定C++的成員函數指針設計有缺陷的觀點,看來是很難的。


在寫這篇文章中,我有一點需要指明:"允許成員函數指針之間進行轉換(cast),而不允許在轉換完成后調用其中的函數",把這個規(guī)則納入C++的標準中是可笑的。首先,很多流行的編譯器對這種轉換不支持(所以,轉換是標準要求的,但不是可移植的)。其次,所有的編譯器,如果轉換成功,調用轉換后的成員函數指針時仍然可以實現你預期的功能:那編譯器就沒有所謂的"undefined behavior(未定義的行為)"這類錯誤出現的必要了(調用(Invocation)是可行的,但這不是標準!)。第三,允許轉換而不允許調用是完全沒有用處的,只有轉換和調用都可行,才能方便而有效地實現委托,從而使這種語言受益。


為了讓你確信這一具有爭議的論斷,考慮一下在一個文件中只有下面的一段代碼,這段代碼是合法的:


class SomeClass;


typedef void (SomeClass::* SomeClassFunction)(void);


void Invoke(SomeClass *pClass, SomeClassFunction funcptr) {

(pClass->*funcptr)(); };


注意到編譯器必須生成匯編代碼來調用成員函數指針,其實編譯器對SomeClass類一無所知。顯然,除非鏈接器進行了一些極端精細的優(yōu)化措施,否則代碼會忽視類的實際定義而能夠正確地運行。而這造成的直接后果是,你可以"安全地"調用從完全不同的其他類中轉換過來的成員函數指針。


為解釋我的斷言的另一半——轉換并不能按照標準所說的方式進行,我需要在細節(jié)上討論編譯器是怎樣實現成員函數指針的。我同時會解釋為什么使用成員函數指針的規(guī)則具有如此嚴格的限制。獲得詳細論述成員函數指針的文檔不是太容易,并且大家對錯誤的言論已經習以為常了,所以,我仔細檢查了一系列編譯器生成的匯編代碼......


轉自:http://dev.csdn.net/htmls/53/53738.html

posted on 2010-12-15 09:19 會飛的兔子 閱讀(378) 評論(0)  編輯 收藏 引用 所屬分類: C++及開發(fā)環(huán)境
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲欧美日韩系列| 国产午夜一区二区三区| 亚洲精选在线| 国产一区二区三区久久| 国产精品久久久久久久午夜| 国产精品二区影院| 国产精品久久久久77777| 国产精品美女999| 国产精品综合视频| 国精品一区二区| 亚洲欧洲日本专区| 亚洲免费观看高清在线观看 | 99精品视频免费观看| 一区二区欧美亚洲| 午夜亚洲性色视频| 模特精品在线| 国产精品久久波多野结衣| 海角社区69精品视频| 亚洲国产成人一区| 亚洲一区二区精品在线观看| 欧美一区二区三区啪啪| 欧美mv日韩mv国产网站app| 亚洲日韩成人| 在线视频精品一| 久久精品女人天堂| 欧美日韩一区二区三区四区在线观看| 国产麻豆日韩欧美久久| 一本久久a久久精品亚洲| 久久精品首页| 一区二区三区回区在观看免费视频| 欧美在线免费视屏| 欧美特黄a级高清免费大片a级| 在线看片日韩| 欧美在线网站| 亚洲视频在线播放| 亚洲黄色av| 国产精品久久久久av免费| 黄色在线一区| 午夜一区二区三视频在线观看| 欧美暴力喷水在线| 亚洲一区国产视频| 欧美精品18+| 在线观看国产一区二区| 性欧美videos另类喷潮| 日韩天堂av| 欧美精品福利| 在线精品亚洲| 美女日韩在线中文字幕| 亚洲一区二区精品| 欧美人与禽性xxxxx杂性| 亚洲第一页在线| 麻豆av一区二区三区| 欧美一区二区三区日韩视频| 国产精品sss| 日韩午夜激情电影| 欧美国产亚洲视频| 久久综合给合| 亚洲国产另类久久精品| 老司机aⅴ在线精品导航| 欧美亚洲视频一区二区| 国产女主播在线一区二区| 亚洲欧美精品suv| 亚洲一区二区免费| 欧美性大战久久久久| 亚洲校园激情| 亚洲一区二区综合| 国产精品影院在线观看| 久久精品国产99国产精品澳门| 亚洲综合色婷婷| 国产一区在线播放| 可以免费看不卡的av网站| 久久久亚洲精品一区二区三区| 在线观看视频一区二区| 亚洲春色另类小说| 欧美日韩你懂的| 午夜精品影院| 玖玖视频精品| 一本大道av伊人久久综合| 99在线|亚洲一区二区| 国产精品视频精品视频| 久久久久看片| 欧美极品在线播放| 欧美在线不卡| 欧美99在线视频观看| 亚洲影视在线| 久久精品国产精品 | 亚洲欧洲在线视频| 欧美日韩在线视频观看| 欧美一级艳片视频免费观看| 久久激情中文| 亚洲深夜福利视频| 久久精品官网| 亚洲一区二区伦理| 国产午夜一区二区三区| 欧美一二三区在线观看| 亚洲欧美一区二区三区久久 | 亚洲国产日韩欧美在线99| 91久久香蕉国产日韩欧美9色| 欧美性猛交视频| 美女主播视频一区| 欧美视频导航| 欧美激情一区二区三区全黄| 国产欧美亚洲日本| 亚洲大片在线| 国产日韩1区| 亚洲精品一区在线观看| 亚洲第一区在线观看| 午夜一区二区三视频在线观看| 日韩视频中文| 久久精品72免费观看| 亚洲一区三区在线观看| 欧美成人中文字幕| 久久国产主播精品| 欧美三级午夜理伦三级中文幕| 欧美99在线视频观看| 国产香蕉久久精品综合网| 一区二区三区四区五区视频| 亚洲国产成人porn| 久久不射中文字幕| 亚洲永久在线观看| 欧美精品色综合| 欧美激情 亚洲a∨综合| 狠狠色丁香婷婷综合| 亚洲一区二区三区精品动漫| 日韩午夜高潮| 欧美精品久久久久久久免费观看 | 亚洲精品中文字幕有码专区| 伊人久久亚洲热| 欧美一级片在线播放| 亚洲一区观看| 欧美日韩一二三区| 亚洲精品精选| 一本色道久久综合亚洲精品婷婷 | 国产婷婷成人久久av免费高清 | 美脚丝袜一区二区三区在线观看| 欧美在线亚洲综合一区| 国产精品久久久久久久午夜片| 99精品视频网| 亚洲一区二区三区四区中文 | 亚洲欧美日韩综合aⅴ视频| 欧美人妖在线观看| 99视频精品免费观看| 亚洲一区二区久久| 国产精品日韩欧美一区二区| 亚洲小说春色综合另类电影| 亚洲欧美在线磁力| 六月婷婷一区| 亚洲一级黄色av| 亚洲国产视频a| 美玉足脚交一区二区三区图片| 久久一区欧美| 亚洲国产精品va在线观看黑人| 欧美国产日本在线| 日韩网站免费观看| 欧美亚洲午夜视频在线观看| 国产乱码精品一区二区三区忘忧草| 亚洲一区二区三区精品在线观看 | 亚洲大胆视频| 亚洲午夜激情网站| 国产麻豆日韩欧美久久| 久久欧美肥婆一二区| 亚洲精品1区2区| 亚洲欧美怡红院| 亚洲国产精品va在线观看黑人| 欧美激情bt| 亚洲综合好骚| 欧美成人午夜剧场免费观看| 夜久久久久久| 国产精品一区二区三区免费观看| 欧美一区二区视频在线观看2020 | 伊人夜夜躁av伊人久久| 欧美88av| 午夜精品久久久久久| 欧美成人一区二区| 亚洲永久网站| 亚洲人午夜精品免费| 国产精品视频区| 欧美另类一区二区三区| 欧美永久精品| 日韩午夜高潮| 男人的天堂成人在线| 亚洲综合精品自拍| 精品电影在线观看| 国产精品一区在线观看你懂的| 久久精选视频| 亚洲一区视频在线观看视频| 蜜桃久久精品一区二区| 亚洲精品在线观看免费| 日韩一区二区福利| 欧美日韩hd| 亚洲午夜黄色| 亚洲一区亚洲| 亚洲一区二区三区高清不卡| 夜夜爽www精品| 黄色精品一二区| 含羞草久久爱69一区| 欧美日韩一卡| 久久综合色8888| 亚洲欧美日韩久久精品| 亚洲美女诱惑|