• <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 - 16,  comments - 34,  trackbacks - 0

            這本應是一個無須爭論的問題——當然必須調用。

            stdarg(或varargs,下略)中提供的功能就是一種契約
            “你按我的約定方式使用這些宏
            ——即必須調用va_end
            ——我就給你提供實現可變長參數列表所需要的功能。”


            使用stdarg本來是簡單的事情
            ——按照一個簡單的契約(另見相關鏈接)辦事就可以了
            ——根本無須了解其具體實現。

            有人樂意去研究該功能是如何實現的, 也很好。


            可是某些人
            ——或通過研究其的實現,或通過實踐
            ——發現他所使用的平臺下, va_end是可以忽略的。
            之后,他就開始大放厥詞 : “va_end是不必要的!”

            由此, 造成一些不必要的誤解與爭論。



            讓我們看看對va_end的兩種態度:



            一、 va_end能省則省?

            假設你使用的某個C/C++編譯器,提供的va_end是可忽略的。
            比如msvc中的va_end的實現如下:
            #define va_end(apap = (va_list)0  /* 將ap置空 */

            通常直接使用va_start的函數(假設叫f)的實現體會很短。:
            1. 用va_start初始化va_list
            2. 調用一個使用va_list參數的函數(假設叫vf
            (vf 是一個固定參數列表的函數)。

            因為f的實現體非常短, 一眼望穿。
            所以你能確保vf返回后, ap不會再被你使用。

            因此, 將ap置空除了浪費CPU周期, 沒有實際意義, 是這樣嗎?


                    一、1.  編譯器參與優化

            你能發現代碼末尾ap不再被使用, va_end將其置空毫無意義。
            那么,你的編譯器能發現這個問題么?

            請查證一下。
            如果編譯器也知道, 并且沒有為va_end生成任何代碼, 那么省略va_end就是不必要的了。

                    一、2. 編譯器不參與優化

            你編譯器真為va_end生成了無意義并且令人感到無法接受的機器碼時,該怎么辦?


                            一、2.1 你只在該編譯器下工作

            那么,你省略va_end好了。
            但請不要宣揚一些帶有誤導性質的言辭。
            當你說“va_end是不需要”的時候, 請附帶說明:
            1. 你的平臺
            2. 你考慮跨平臺


                            一、2.2 需要要考慮移植到其他編譯器

            注意, 其他編譯器包括(但不限于):
            ——不同架構上的編譯器
            ——相同架構上的不同編譯器產品
            ——相同架構上的相同編譯器產品的不同版本

            需要分析在該編譯器下,對va_end的處理是否依然可以被省略
            ——顯然,這是一項乏味的工作。


            即使你在源代碼中寫入 :

            /* va_end is trivial, omit it */

            也難保它不會被遺忘
            —— 移植一個程序的時候有太多工作要做。
            這么一個不起眼的地方, 會被想起來么?


            如果在被移植的編譯器上:
            1. 省略va_end將導致函數不能正常返回(見附錄)
            也許立馬就能發現這個bug。
            崩掉了嘛, 當然要引起“重視”。

            2. 省略va_end不會立馬崩潰, 而是導致內存泄露(見附錄)
            情況就很嚴重了。
            程序依然運行“良好”。
            但是調用一次函數, 就泄漏一點點內存。

            這恐怕就要花很多時間才能查出來了。
            如果項目時間再緊一點, 也許根本就來不及修復這個bug就發布了。
            反正漏得也“不多”, 你說是吧?



            二、 va_end能留則留

            我們何不換個方式?

            1.  堅持使用va_end
            ——即便我們心里清楚它沒做什么有用的事情也是如此。

            代碼移植本質就是: 不對平臺(CPU、OS、Compiler等等)產生依賴
            stdarg就是標準庫提供的一種實現可變長參數列表的可移植方式。
            我們沒理由棄之不用。

            如果我們在源代碼中堅持使用va_end:
            ——至少在這點上,就不會對編譯器產生依賴(而省略va_end,就是一種依賴)。
            ——移植的時候, 自然無須為其操心。

            2. va_end令編譯器產生了令人無法接受無用代碼時
            ——通常,這是不會發生的。 編譯器廠商會考慮這個事情。

            比如上面的va_end宏, 會產生一次不必要的賦值操作, 但通常會被編譯器優化為空。
            即使沒有被優化為空, 一次賦值操作, 真的就是不可容忍的么?

            如果確實不能容忍, 作為一種特殊情形, 可以這樣 :

            #if defined(COMPILER1) || defined(COMPILER2|| ...
                
            /*special situation
                    the machine code generated by these compliers is unacceptable, omit it
                
            */
            #else
                
            /* general situation */
                va_end(ap);
            #endif




            附錄 —— 看看大牛們是怎么說的。

            從一個使用過va_start()的函數中退出之前,必須調用一次va_end()。
            這是因為va_start可能以某種方式修改了堆棧,這種修改可能導致返回無法完成,va_end()能將有關的修改復原。
                            ——《C++程序設計語言》 第3版、特別版, p139
            ——即上面提到的 “立即崩潰”。


            我們務必記住,在使用完va_list變量后一定要調用宏va_end。
            大多數C實現上,調用va_end與否并無區別
            但是,某些版本的va_start宏為了方便對va_list的遍歷,就給參數列表動態分配內存
            這樣一種C實現很可能利用va_end宏來釋放此前動態分配的內存;
            如果忘記調用宏va_end,最后得到的程序可能在某些機型上沒有問題,而在另一些機型上則發生“內存泄露”。
                            ——《C陷阱與缺陷》, p161
            ——即上面提到的“內存泄露”。



            …… 最后,必須在函數返回之前調用va_end,以完成一些必要的清理工作。
                            ——《C程序設計語言》 第2版, p137

            ……在所有參數處理完畢后, 且在退出函數f之前必須調用宏va_end一次 ……
                            ——《C程序設計語言》 第2版, p232

             



            相關鏈接:


            ——可變長參數列表誤區與陷阱——va_arg不可接受的類型
            http://www.shnenglu.com/ownwaterloo/archive/2009/04/21/unacceptable_type_in_va_arg.html
            這是使用stdarg提供的功能需要遵守契約之一。
            契約本身仍然是簡單的。
            契約背后的原理也許比較晦澀, 但也可以不必關心。



            Creative Commons License
            作品采用知識共享署名-非商業性使用-相同方式共享 2.5 中國大陸許可協議進行許可。

            轉載請注明 :
            文章作者 - OwnWaterloo
            發表時間 - 2009年04月21日
            原文鏈接 - http://www.shnenglu.com/ownwaterloo/archive/2009/04/21/is_va_end_necessary.html
            posted on 2009-04-21 15:53 OwnWaterloo 閱讀(4930) 評論(2)  編輯 收藏 引用

            FeedBack:
            # re: 可變長參數列表誤區與陷阱——va_end是必須的嗎?
            2009-04-22 09:05 | abettor
            我有個工程運行1周左右就死,可以肯定的是內存泄漏,但是調試了很多次,甚至帶上Visual Leak Detector(自己看源代碼查更是不知道多少遍了),也一直沒有找到泄漏的地方。

            我一直注意看的是new-delete和malloc-free的匹配,還真沒有想到這里還有泄漏的可能,我決定再仔細找找。  回復  更多評論
              
            # re: 可變長參數列表誤區與陷阱——va_end是必須的嗎?
            2009-05-02 16:50 | sswv
            受教了。  回復  更多評論
              
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(8)

            隨筆檔案(16)

            鏈接

            搜索

            •  

            積分與排名

            • 積分 - 197904
            • 排名 - 133

            最新隨筆

            最新評論

            閱讀排行榜

            評論排行榜

            成人国内精品久久久久影院VR| 日韩av无码久久精品免费| 久久青青草原综合伊人| 一97日本道伊人久久综合影院| 2021少妇久久久久久久久久| 亚洲国产成人乱码精品女人久久久不卡| 精品人妻伦一二三区久久| 国产精品久久久久国产A级| 天天做夜夜做久久做狠狠| 久久99久久99精品免视看动漫| 青青青青久久精品国产| 久久久久国产亚洲AV麻豆| 久久国产精品成人免费| 久久Av无码精品人妻系列| 午夜精品久久久久久| 少妇精品久久久一区二区三区| 久久久久波多野结衣高潮| 欧美久久亚洲精品| 91精品国产91久久久久福利| 日本欧美国产精品第一页久久| 高清免费久久午夜精品| 久久精品中文无码资源站| 一本久久久久久久| 久久精品成人免费观看97| 欧美熟妇另类久久久久久不卡 | 99久久国产精品免费一区二区| 久久精品无码专区免费| 2021精品国产综合久久| 久久夜色精品国产网站| 久久亚洲精品国产亚洲老地址| 一本一道久久综合狠狠老| 久久九九久精品国产免费直播| 色综合久久久久| 久久99免费视频| 麻豆精品久久精品色综合| 2020最新久久久视精品爱 | 久久精品国产色蜜蜜麻豆| 国产一级做a爰片久久毛片| 国产精品久久亚洲不卡动漫| 久久精品国产亚洲一区二区| 国产成人久久激情91|