• <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>

            Note of Justin

            關于工作和讀書的筆記

              C++博客 :: 首頁 :: 聯系 :: 聚合  :: 管理
              47 Posts :: 0 Stories :: 45 Comments :: 0 Trackbacks

            留言簿(14)

            搜索

            •  

            積分與排名

            • 積分 - 53109
            • 排名 - 433

            最新評論

            閱讀排行榜

            評論排行榜

            [原創文章歡迎轉載,但請保留作者信息]
            Justin 于 2009-12-19


            在認真學習第20課后,大師有點擔心學生馬上變成傳引用(pass-by-reference)的粉絲。為了辯證的看待問題,下一課現在開講……
            初看題目,第21條玉律說的也是一個很簡單的情況:如果函數需要返回一個對象,就不要僅僅返回引用,因為返回的引用有可能已經指向一個不存在的對象了。
            沒錯,不過細讀下去發現還是有一些的細節自己原來并沒有考慮到。

            如果函數返回的是值(對象),那么就難免要進行創建對象操作(構造/析構)來存儲返回的結果;如果是返回引用,就可以避免這額外的對象創建,節省了資源和時間。
            看來,似乎返回引用要優于返回整個對象。

            是這樣么?大師繼續揭開更本質的一些東西:
            如果一個函數可能返回一個對原來不存在的對象的引用,那么函數就要自己去創建這個對象:要么在棧上(stack)要么在堆上(heap)。

            • 第一種情況中,函數中定義了局部對象,然后返回對該對象的引用。對象在函數結束后自動銷毀,引用指向無效的地址。
              OK,很簡單。
            • 第二種情況,函數使用new動態創建了一個對象,然后返回對該對象的引用。粗看沒有問題,因為這個返回的引用還是有效的。
              但是細想就會發現:我們能確保這個對象被正確的收回(delete)嗎?
              • 書中舉了一個很好的例子:一個*運算符函數,接受兩個乘法運算數,返回一個積。
                如果在函數中動態創建一個對象來存儲乘積,并返回對這個新對象的引用,那么下面的計算就會帶來內存泄漏:
                ??
                Y=A*B*C
                因為在這個“連續”乘法中,有兩個“乘積對象”被創建,但是我們丟失了第一次乘法創建的對象的指針。
                所以這樣的做法是不妥的。

            也許大師有被問過:那么對于第一種情況我們可不可以返回一個靜態(static)對象的引用?書中用了同樣的例子來回答:NO。
            ?? if (A*B == C*D) {//..}
            如果返回靜態對象的引用,上面的判斷語句永遠得到true值,因為“==”號兩邊的運算結果是指向同一塊數據的引用。

            不知道是不是后面又有刨根問題的學生追問:那我能不能用一個靜態對象的數組來存放不同此運算的結果?大師懶得舉例子了,我猜想也沒必要:這樣的方案帶來的副作用及其開銷本身就已經大于原來要解決的問題了吧?

            最后總結本課中心思想:

            1. 不要嘗試在函數中返回對局部對象(存儲于棧)的引用,也不要對動態創建的對象(存儲于堆)做同樣的蠢事,而如果真有打算、非常渴望、十分想要返回對靜態對象的引用,在這么做之前也要考慮清楚會不會有上面例子中的情況出現。
            2. 至少,返回對象不會有上面列出的種種錯誤危險,僅僅是有可能帶來創建額外對象的開銷而已,而這個開銷的可能還有可能被排除,如果你用的編譯器足夠聰明的話。

            下課!
            謝~謝~老~師~

            posted on 2010-01-06 08:30 Justin.H 閱讀(1701) 評論(1)  編輯 收藏 引用 所屬分類: Effective C++ 炒冷飯

            Feedback

            # re: Effective C++ 炒冷飯 - Item 21 該返回值的時候別返回引用 2010-01-07 22:18 劉暢
            今晚剛看了這一章,呵呵,感覺大師的這本書真的很好啊!  回復  更多評論
              

            91麻豆精品国产91久久久久久| 中文成人无码精品久久久不卡| 久久人人爽人人爽人人片AV东京热 | 99久久www免费人成精品| 国产精品免费看久久久| 国产亚洲欧美精品久久久| 狠狠综合久久综合中文88| 久久久国产打桩机| 中文字幕成人精品久久不卡| 亚洲国产成人久久综合碰| 久久久久久久久久久久久久| 97久久久精品综合88久久| 久久伊人中文无码| 97超级碰碰碰碰久久久久| 99久久香蕉国产线看观香| 四虎国产永久免费久久| 久久久久波多野结衣高潮| 欧美麻豆久久久久久中文| 国产99久久九九精品无码| 日本精品久久久久中文字幕| 精品久久久久久国产潘金莲| 国产精品久久久久久久久软件| 狠狠色伊人久久精品综合网| 999久久久免费国产精品播放| 国产亚洲色婷婷久久99精品| 精品一区二区久久| 狠狠人妻久久久久久综合蜜桃| 久久本道久久综合伊人| 久久亚洲AV无码精品色午夜麻豆| 伊人久久大香线蕉精品不卡| 亚洲欧洲精品成人久久曰影片| 久久强奷乱码老熟女网站| 久久精品国产亚洲AV无码偷窥| 国产精品久久久久aaaa| 日产精品久久久一区二区| 精品国产福利久久久| 久久久久久九九99精品| 欧美一级久久久久久久大| 久久综合伊人77777| 亚洲欧美伊人久久综合一区二区 | 久久精品国产精品亜洲毛片|