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

            搜索

            •  

            積分與排名

            • 積分 - 52516
            • 排名 - 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 閱讀(1691) 評論(1)  編輯 收藏 引用 所屬分類: Effective C++ 炒冷飯

            Feedback

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

            色欲av伊人久久大香线蕉影院| 精品国产乱码久久久久久浪潮 | 日本加勒比久久精品| 亚洲?V乱码久久精品蜜桃| 久久人人爽人人爽人人爽 | 亚洲国产成人久久笫一页| 国产成人精品白浆久久69 | 麻豆亚洲AV永久无码精品久久 | 88久久精品无码一区二区毛片 | 久久久久久国产精品无码下载| 无码AV波多野结衣久久| 999久久久国产精品| 好久久免费视频高清| 亚洲午夜无码AV毛片久久| 久久青青草原亚洲av无码app| 久久久精品国产免大香伊 | 亚洲精品乱码久久久久久按摩| 久久精品国产久精国产| 18岁日韩内射颜射午夜久久成人| 热RE99久久精品国产66热| 久久国产精品无码HDAV| 久久国产欧美日韩精品| 久久亚洲视频| 精品国产日韩久久亚洲| 久久九九兔免费精品6| 久久久久久久综合日本| 久久精品国产亚洲5555| 久久99久久99小草精品免视看| 色综合久久无码五十路人妻| 亚洲Av无码国产情品久久| 久久精品无码专区免费| 久久久久亚洲AV成人网人人网站| 亚洲精品高清国产一久久| 国产精品久久久久天天影视| 国产精品免费久久久久影院| 香蕉久久夜色精品国产尤物| 亚洲精品乱码久久久久久蜜桃| 久久五月精品中文字幕| 欧美亚洲日本久久精品| 亚洲精品视频久久久| 久久亚洲sm情趣捆绑调教|