[問題] 什麼時後 不該用/該用reference當member

看板C_and_CPP作者 (JOMI)時間7年前 (2018/07/23 19:16), 7年前編輯推噓6(6029)
留言35則, 10人參與, 7年前最新討論串1/4 (看更多)
寫一個建構子 Foo(ICallback* callback) : mCallback(callback){ assert(mCallback); } 被問說那為什麼你mCallback不用reference 然後Foo就開成(ICallback&)就好 我不想這樣改 但我沒有強力的說法比較出哪一種比較好或是合理 我的看法 用ref, caller勢必要*ptr 做dereference才能傳進來 雖然說reference 可以當作non null去操作 但有心要傳*null也不是不行. 開reference 給別人傳,比起pointer更有機會caller不小心傳入local variable 以上都可以用一句話“哪有人會這樣寫”來否定用pointer存. 而用reference 可以給人一種 必定要想辦法生出一個物件才能呼叫的感覺... 實在想不到哪個時候 用reference 才是合理的寫法. 反而我自己是很少看過member 用reference去存... 不知道大家在design上會有什麼考量 謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 39.8.8.45 ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1532344601.A.2C0.html ※ 編輯: lovejomi (39.8.8.45), 07/23/2018 19:36:57

07/23 19:47, 7年前 , 1F
我覺得你把物件變數的記憶體控管交出去就開始錯了
07/23 19:47, 1F

07/23 19:51, 7年前 , 2F
要嘛寫member function把生member variable的部分封裝
07/23 19:51, 2F

07/23 19:52, 7年前 , 3F
起來給使用者call 要嘛丟進來的東西你自己再new一塊做
07/23 19:52, 3F

07/23 19:53, 7年前 , 4F
copy
07/23 19:53, 4F

07/23 20:21, 7年前 , 5F
我覺得smart pointer唯一解
07/23 20:21, 5F

07/23 20:26, 7年前 , 6F
沒有說明Foo跟ICallBack的生命週期跟擁有權沒辦法回答
07/23 20:26, 6F

07/23 20:28, 7年前 , 7F
你的看法那段的理由我覺得還蠻弱的 我會預設用ref
07/23 20:28, 7F

07/23 20:28, 7年前 , 8F
不用ref的理由, class需要被copy
07/23 20:28, 8F

07/23 20:32, 7年前 , 9F
生命周期都比這class本身久, 我知道理由很弱,但我很
07/23 20:32, 9F

07/23 20:32, 7年前 , 10F
難描述我不想用ref的理由,總覺得不夠彈性
07/23 20:32, 10F

07/23 22:15, 7年前 , 11F
阿對還有smart pointer這個解 我老了QQ
07/23 22:15, 11F

07/23 22:40, 7年前 , 12F
std::function 選我正解好嗎
07/23 22:40, 12F

07/23 23:35, 7年前 , 13F
你要考慮callback生命週期 用reference傳入的話
07/23 23:35, 13F

07/23 23:35, 7年前 , 14F
其實有很高的機率會發生人為錯誤
07/23 23:35, 14F

07/23 23:36, 7年前 , 15F
pointer除非耍蠢 很不自然的傳一個local variable的
07/23 23:36, 15F

07/23 23:36, 7年前 , 16F
pointer進來 不然基本上不太會出包 但ref機率高得多
07/23 23:36, 16F

07/23 23:37, 7年前 , 17F
另外 smart pointer是通用解沒錯...
07/23 23:37, 17F

07/24 00:44, 7年前 , 18F
我的習慣是如果會改變外部狀態就用指標,使用但是不會
07/24 00:44, 18F

07/24 00:45, 7年前 , 19F
去改變外部就用ref(常常搭配const來保證不會修改)
07/24 00:45, 19F

07/24 00:50, 7年前 , 20F
還需要擔心生命週期的情況就都用std::shared_ptr處理
07/24 00:50, 20F

07/24 02:23, 7年前 , 21F
ref比較好,B(A&),如果正確依照物件生命週期設計,乾淨的
07/24 02:23, 21F

07/24 02:23, 7年前 , 22F
程式結構會是B先結束,之後才是A結束,用pointer會變成語
07/24 02:23, 22F

07/24 02:23, 7年前 , 23F
法上少了限制,隨便寫都會產生cyclic dependency的問題,
07/24 02:23, 23F

07/24 02:23, 7年前 , 24F
造成物件生命週期結束這塊非常難寫,然後系統資源沒釋放
07/24 02:23, 24F

07/24 02:23, 7年前 , 25F
完,浪費工程師的生命在找問題,最後跟你說解決的辦法是定
07/24 02:23, 25F

07/24 02:23, 7年前 , 26F
期reset整臺機器…簡單講B(A&)很自然就從語法上讓你設計
07/24 02:23, 26F

07/24 02:23, 7年前 , 27F
出遵循著RAII的程式結構
07/24 02:23, 27F

07/24 05:47, 7年前 , 28F
從語法層級探討很沒意義,高興怎樣就怎樣啊,真非要用
07/24 05:47, 28F

07/24 05:47, 7年前 , 29F
reference 還有 reference_wrapper 可以活用。
07/24 05:47, 29F

07/24 05:48, 7年前 , 30F
正確來講還是要從生命週期去探討,用更高階抽象的概念來
07/24 05:48, 30F

07/24 05:48, 7年前 , 31F
說就是 aggregation 跟 composition 的差異。
07/24 05:48, 31F

07/24 05:49, 7年前 , 32F
如果對這兩個名詞陌生,可能要去補足一下 OOAD 的知識。
07/24 05:49, 32F

07/24 05:50, 7年前 , 33F
身為一名工程師,設計圖之類的當然要會畫,然後按圖施工
07/24 05:50, 33F

07/24 05:50, 7年前 , 34F
,今天會有這種問題跑出來就是因為你沒圖。
07/24 05:50, 34F

07/28 12:57, 7年前 , 35F
reference 不能直接更換綁定對象
07/28 12:57, 35F
文章代碼(AID): #1RLRaPB0 (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #1RLRaPB0 (C_and_CPP)