看板 C_and_CPP 關於我們 聯絡資訊
※ 引述《Ebergies (火神)》之銘言: : → loveme00835:你說的是使用上, 而我說的是介面的參數傳遞, 參數的用 04/09 01:40 : → loveme00835:法跟變數根本不一樣, 在 C++03 ref to const l-value 04/09 01:41 : → loveme00835:也兼具了建構暫時物件的任務, 並不是單純以資料量的差 04/09 01:42 : → loveme00835:別來區分 04/09 01:43 其實我看不懂兩位大大的論點有什麼針鋒相對的地方 若不討論 r-value ref, 常見的就這四種: 1) T * 2) const T * 3) T & 4) const T & 若是 3 和 4, 也就是使用 ref 的情況, 基本上暗示了 "這個實體在這個 scope 內其生命週期不會消失" 但 3 其內容可能被修改, 4 則不會 2 的意義和 4 差不多, 但它可以允許傳入空值 (null_ptr) 1 則是其生命週期有可能在 scope 內消失 所以該用哪一個應該是策略上的問題 說實在我最不懂的地方是 ... 這跟原題有啥關係 囧rz -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.205.248.119
loveme00835:相依性談到類別實作, 再談到引數傳遞, 我的看法是偏向 04/09 01:57
loveme00835:只做1 4, 可以達成你所說的所有策略, 你不想要引數被 04/09 01:58
loveme00835:改, 就不用加個 &再傳進來, 那麼我實作也可以by value 04/09 01:59
loveme00835:by ref 任意作切換, 但是有必需要加 &的場合, 順便也 04/09 01:59
loveme00835:提醒呼叫端這樣作物件可能被收回, 傳入空值通常會改用 04/09 02:00
loveme00835:多載來作, 才不會被多個指標的signature混淆 04/09 02:01
legnaleurc:但是這會變成 client 端自己要注意什麼時候要加 & 04/09 02:03
legnaleurc:至少我看到 1 的型別時, 下意識會想到它有可能會取得 04/09 02:05
legnaleurc:生殺大權. 如果你根本不打算動它的主意, T & 應該會比 04/09 02:06
legnaleurc:較明確 04/09 02:06
loveme00835:特別的地方總是引人注目的, 全部加&麻煩, 全部ref其實 04/09 02:07
loveme00835:會讓人較容易記憶體釋放的問題, 再加上混雜 by value 04/09 02:09
loveme00835:傳遞的函式, 沒辦法一眼就分辨得出來語意的 04/09 02:10
legnaleurc:呃, 這樣我不知道要怎麼回, 看起來完全是 style 的問題 04/09 02:15
loveme00835:其實不是我這樣說而已啦, 記得 coding standard也有 04/09 02:16
legnaleurc:如果整套介面都用同樣的策略設計, client 也能接受的話 04/09 02:16
legnaleurc:其實都不是什麼大問題 04/09 02:16
legnaleurc:你是說 C++ coding standard 那本嗎? 我怎麼不記得有 04/09 02:16
legnaleurc:你說的條款? 再說這其實跟紅綠燈一樣, 很多都參考用的 04/09 02:17
legnaleurc:有牽涉到的 client 用起來滿意就好了唄 04/09 02:18
loveme00835:ch 25有講到一些, 說的也對, 用得爽就好:) 04/09 02:21