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

            我們從 UNREFERENCED_PARAMETER 開始吧。這個(gè)宏在 winnt.h 中定義如下:

            #define UNREFERENCED_PARAMETER(P) (P)

              換句話說(shuō) UNREFERENCED_PARAMETER 展開傳遞的參數(shù)或表達(dá)式。其目的是避免編譯器關(guān)于未引用參數(shù)的警告。許多程序員,包括我在內(nèi),喜歡用最高級(jí)別的警告 Level 4(/W4)進(jìn)行編譯。Level 4 屬于“能被安全忽略的事件”的范疇。雖然它們可能使你難堪,但很少破壞你的代碼。例如,在你的程序中可能會(huì)有這樣一些代碼行:

            int x=1;

              但你從沒(méi)用到過(guò) x。也許這一行是你以前使用 x 時(shí)留下來(lái)的,只刪除了使用它的代碼,而忘了刪除這個(gè)變量。Warning Level 4 能找到這些小麻煩。所以,為什么不讓編譯器幫助你完成可能是最高級(jí)別的專業(yè)化呢?用Level 4 編譯是展示你工作態(tài)度的一種方式。如果你為公眾使用者編寫庫(kù),Level 4 則是社交禮節(jié)上需要的。你不想強(qiáng)迫你的開發(fā)人員使用低級(jí)選項(xiàng)清潔地編譯他們的代碼。
              問(wèn)題是,Level 4 實(shí)在是太過(guò)于注意細(xì)節(jié),在 Level 4 上,編譯器連未引用參數(shù)這樣無(wú)傷大雅的事情也要抱怨(當(dāng)然,除非你真的有意使用這個(gè)參數(shù),這時(shí)便相安無(wú)事)。假設(shè)你有一個(gè)函數(shù)帶來(lái)兩個(gè)參數(shù),但你只使用其中一個(gè):

            int SomeFunction(int arg1, int arg2){  return arg1+5;}

            使用 /W4,編譯器抱怨:

            “warning C4100: ''arg2'' : unreferenced formal parameter.”

            為了騙過(guò)編譯器,你可以加上 UNREFERENCED_PARAMETER(arg2)。現(xiàn)在編譯器在編譯你的引用 arg2 的函數(shù)時(shí)便會(huì)住口。并且由于語(yǔ)句:

            arg2;

            實(shí)際上不做任何事情,編譯器不會(huì)為之產(chǎn)生任何代碼,所以在空間和性能上不會(huì)有任何損失。

              細(xì)心的人可能會(huì)問(wèn):既然你不使用 arg2,那當(dāng)初為何要聲明它呢?通常是因?yàn)槟銓?shí)現(xiàn)某個(gè)函數(shù)以滿足某些API固有的署名需要,例如,MFC的 OnSize 處理例程的署名必須要像下面這樣:

            void OnSize(UINT nType, int cx, int cy);

              這里 cx/cy 是窗口新的寬/高,nType 是一個(gè)類似 SIZE_MAXIMIZED 或 SIZE_RESTORED 這樣的編碼,表示窗口是否最大化或是常規(guī)大小。一般你不會(huì)在意 nType,只會(huì)關(guān)注 cx 和 xy。所以如果你想用 /W4,則必須使用 UNREFERENCED_PARAMETER(nType)。OnSize 只是上千個(gè) MFC 和 Windows 函數(shù)之一。編寫一個(gè)基于 Windows 的程序,幾乎不可能不碰到未引用參數(shù)。
              說(shuō)了這么多關(guān)于 UNREFERENCED_PARAMETER 內(nèi)容。Judy 在她的問(wèn)題中還提到了另一個(gè) C++ 程序員常用的并且其作用與 UNREFERENCED_PARAMETER 相同的訣竅,那就是注釋函數(shù)署名中的參數(shù)名:

            void CMyWnd::OnSize(UINT , int cx, int cy){}

              現(xiàn)在 nType 是未命名參數(shù),其效果就像你敲入 OnSize(UINT, int cx, int cy)一樣。那么現(xiàn)在的關(guān)鍵問(wèn)題是:你應(yīng)該使用哪種方法——未命名參數(shù),還是 UNREFERENCED_PARAMETER?
              大多數(shù)情況下,兩者沒(méi)什么區(qū)別,使用哪一個(gè)純粹是風(fēng)格問(wèn)題。(你喜歡你的 java 咖啡是黑色還是奶油的顏色?)但我認(rèn)為至少有一種情況必須使用 UNREFERENCED_PARAMETER。假設(shè)你決定窗口不允許最大化。那么你便禁用 Maximize 按鈕,從系統(tǒng)菜單中刪除,同時(shí)阻止每一個(gè)用戶能夠最大化窗口的操作。因?yàn)槟闶瞧珗?zhí)狂(大多數(shù)好的程序員都是偏執(zhí)狂),你添加一個(gè) ASSERT (斷言)以確保代碼按照你的意圖運(yùn)行:

            void CMyWnd::OnSize(UINT nType, int cx, int cy){  ASSERT(nType != SIZE_MAXIMIZE);  ... // use cx, cy}

              質(zhì)檢團(tuán)隊(duì)竭盡所能以各種方式運(yùn)行你的程序,ASSERT 從沒(méi)有彈出過(guò),于是你認(rèn)為編譯生成 Release 版本是安全的。但是此時(shí) _DEBUG 定義沒(méi)有了,ASSERT(nType != SIZE_MAXIMIZE)展開為 ((void)0),并且 nType 一下子成了一個(gè)未引用參數(shù)!這樣進(jìn)入你干凈的編譯。你無(wú)法注釋掉參數(shù)表中的 nType,因?yàn)槟阋?ASSERT 中使用它。于是在這種情況下——你唯一使用參數(shù)的地方是在 ASSERT 中或其它 _DEBUG 條件代碼中——只有 UNREFERENCED_PARAMETER 會(huì)保持編譯器在 Debug 和 Release 生成模式下都沒(méi)有問(wèn)題。知道了嗎?
              結(jié)束討論之前,我想還有一個(gè)問(wèn)題我沒(méi)有提及,就是你可以象下面這樣用 pragma 指令抑制單一的編譯器警告:

            #pragma warning( disable : 4100 )

            4100 是未引用參數(shù)的出錯(cuò)代碼。pragma 抑制其余文件/模塊的該警告。用下面方法可以重新啟用這個(gè)警告:

            #pragma warning( default : 4100 )

              不管怎樣,較好的方法是在禁用特定的警告之前保存所有的警告狀態(tài),然后,等你做完之后再回到以前的配置。那樣,你便回到的以前的狀態(tài),這個(gè)狀態(tài)不一定是編譯器的默認(rèn)狀態(tài)。
              所以你能象下面這樣在代碼的前后用 pragma 指令抑制單個(gè)函數(shù)的未引用參數(shù)警告:

            #pragma warning( push ) #pragma warning( disable : 4100 )void SomeFunction(...){}#pragma warning( pop )

              當(dāng)然,對(duì)于未引用參數(shù)而言,這種方法未免冗長(zhǎng),但對(duì)于其它類型的警告來(lái)說(shuō)可能就不是這樣了。庫(kù)生成者都是用 #pragma warning 來(lái)阻塞警告,這樣他們的代碼可以用 /W4 進(jìn)行清潔編譯。MFC 中充滿了這樣的 pragmas 指令。還有好多的 #pragma warning 選項(xiàng)我沒(méi)有在本文討論。有關(guān)它們的信息請(qǐng)參考相關(guān)文檔。

            posted on 2009-04-17 10:55 Madison 閱讀(211) 評(píng)論(0)  編輯 收藏 引用

            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(1)

            隨筆檔案

            搜索

            •  

            積分與排名

            • 積分 - 1897
            • 排名 - 2063

            最新評(píng)論

            • 1.?我我
            • re: 我發(fā)誓拒絕戀愛(ài)
            • --我我
            • 2.?re: 我發(fā)誓
            • @何孟東
              呵呵,我倒是想玩來(lái)著。不過(guò)機(jī)器前陣不知道怎么抽風(fēng)之后WC死活就沒(méi)有聲音了。重裝,還原都試了就是不行,郁悶不止一點(diǎn)點(diǎn) T_T
            • --Sunshine Alike
            • 3.?re: 我發(fā)誓
            • 評(píng)論內(nèi)容較長(zhǎng),點(diǎn)擊標(biāo)題查看
            • --星綻紫輝
            • 4.?re: 我發(fā)誓
            • war3@Sunshine Alike
            • --何孟東
            • 5.?re: 我發(fā)誓
            • 哈哈,LZ是說(shuō)WOW還是WC3啊?
            • --Sunshine Alike

            閱讀排行榜

            評(píng)論排行榜

            久久精品国产亚洲精品| 午夜不卡888久久| 精品久久久久久国产| 久久精品www人人爽人人| 久久亚洲高清观看| 国产精品久久久久a影院| 久久综合综合久久综合| 久久www免费人成精品香蕉| 99蜜桃臀久久久欧美精品网站 | 国产精品美女久久久久网| 久久久久亚洲AV综合波多野结衣 | 久久大香香蕉国产| 国产精品久久久久久五月尺| 久久美女网站免费| 亚洲AV乱码久久精品蜜桃| 久久黄色视频| 亚洲国产精品久久| 久久久久久夜精品精品免费啦 | 99国产精品久久| 精品久久久久久国产| 中文成人无码精品久久久不卡| 国产精品综合久久第一页| 国产精品禁18久久久夂久| 精品多毛少妇人妻AV免费久久| 性做久久久久久久久| 久久精品无码一区二区日韩AV| 91久久精品电影| 久久伊人精品青青草原高清| 99久久国产热无码精品免费| 久久久久亚洲av无码专区导航| 欧美伊人久久大香线蕉综合| 中文国产成人精品久久亚洲精品AⅤ无码精品 | 欧美喷潮久久久XXXXx| 午夜精品久久久久久久久| 久久精品国产清自在天天线| 久久AV高潮AV无码AV| 伊人久久大香线焦AV综合影院| 伊人久久精品无码二区麻豆| 久久国产热精品波多野结衣AV| 无码人妻精品一区二区三区久久 | 亚洲精品乱码久久久久久蜜桃|