PTT數位生活區 / C_and_CPP (C/C++)

[問題] rvalue reference 的應用

看板C_and_CPP (C/C++)作者 (CA)時間15年前 (2011/02/07 21:04), 編輯推噓4(4推 0噓 36→)
留言40則, 5人參與, 最新討論串1/1
前陣子書唸不下去跑去玩 rvalue reference 為自己有 value 語意的 classes 都加上 move constructor 和 move assignment operator 但是在應用上發現一點小問題 在原文介紹中寫了一個像這樣的範例: s1 + " " + s2 + " " + s3 ... blah blah 由於+運算是左結合, 所以實際上要寫出 V operator +( T &&, const U & ) 這種簽名的非成員重載才有用 再來看另一種情況, 假設有個很喜歡 jQuery 風格的人 把他的函式庫弄得跟 jQuery 寫法一樣: String( "bb" ).replace( 0, 3 ).reverse().prepend( "aaa" ).length() 那麼這是不是很難受益於 rvalue reference? (假設它們都回傳一個暫時物件, 不是 reference. 他可能喜歡 immutable string) 因為 operator 可以有非成員重載, 但具名函式卻不行 直接 return 一個 rvalue reference 好像也怪怪的 另外, 考慮到各種不同的 bind 狀況 同樣的 binary operator 似乎也需要做多種不同的 overloading 這時候是否是使用 std::forward 來把原本是 member operator 的 版本 forward 給一個 nonmember operator 版本? 後來越寫感到越奇怪, 就停在 move ctor/operator = 的階段 因為越想好像就要寫越多重載版本 = = -- 自High筆記（半荒廢) http://legnaleurc.blogspot.com/ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.205.248.119
推
02/07 22:16, , 1F
第一個問號: 你無法知道自己是不是暫時物件, 第二個問
02/07 22:16, 1F
→
02/07 22:17, , 2F
號 + 的實作通常是委派給 +=, 其他類似的運算子也是如
02/07 22:17, 2F
→
02/07 22:18, , 3F
此, 要讓自己的類別使用起來像內建型態非常的不容易,
02/07 22:18, 3F
→
02/07 22:19, , 4F
光std::string就作了很多奇怪的重載版本, 不過也多虧
02/07 22:19, 4F
→
02/07 22:20, , 5F
他這麼麻煩, 才不會讓程式設計師寫出很多語意很奇怪的
02/07 22:20, 5F
→
02/07 22:21, , 6F
碼, r-value ref 是用來增加效率, 並不是用來補強為了
02/07 22:21, 6F
→
02/07 22:21, , 7F
語法方便所帶來的副作用
02/07 22:21, 7F
→
02/07 23:26, , 8F
我想這就是我的問題, 自己就是個暫時物件的情況
02/07 23:26, 8F
→
02/07 23:27, , 9F
其比例並不算小, 但 rvalue ref 給我的感覺是它比較適
02/07 23:27, 9F
→
02/07 23:27, , 10F
合用在 operand 上 ... 至少語法上比較方便
02/07 23:27, 10F
推
02/07 23:39, , 11F
自己是暫時物件的情況比較常出現是在作為函式引數的情
02/07 23:39, 11F
→
02/07 23:40, , 12F
況, 就像 binary operator, 像您這樣用暫時物件再產生
02/07 23:40, 12F
→
02/07 23:41, , 13F
更多暫時物件的情況是比較不被建議使用的, 如
02/07 23:41, 13F
→
02/07 23:42, , 14F
Exceptional C++ 一書中所提到的, 不只中途可能出錯
02/07 23:42, 14F
→
02/07 23:42, , 15F
測試的複雜度也會提高
02/07 23:42, 15F
推
02/08 00:20, , 16F
考慮這樣的敘述 obj2 = (obj1 = Object()).clone();
02/08 00:20, 16F
→
02/08 00:21, , 17F
這樣的資源應該由誰來擁有呢?
02/08 00:21, 17F
→
02/08 00:23, , 18F
括號內就已經算是左值了吧
02/08 00:23, 18F
→
02/08 00:23, , 19F
挖勒上面例子舉得不太好...Orz
02/08 00:23, 19F
→
02/08 00:24, , 20F
我的意思是你總不可能每產生一次暫時物件就用一個左值
02/08 00:24, 20F
→
02/08 00:25, , 21F
去接, 比方說 Qt 的 QString::arg() 系列
02/08 00:25, 21F
→
02/08 00:26, , 22F
正常人都會用 s.arg().arg() 的方式去用它
02/08 00:26, 22F
→
02/08 00:31, , 23F
所以最後這是使用者的責任嗎? 在確定是右值的狀況下
02/08 00:31, 23F
→
02/08 00:32, , 24F
用 std::move 來強制指定?
02/08 00:32, 24F
→
02/08 00:32, , 25F
我怎麼覺得在 Data Flow Testing 的觀點這是不正常的
02/08 00:32, 25F
→
02/08 00:33, , 26F
不過仔細想想 ... 好像也沒用, 怎麼讓 *this 變右值?
02/08 00:33, 26F
→
02/08 00:33, , 27F
用法...java這樣作是可以再作進一步的最佳化或用heap
02/08 00:33, 27F
→
02/08 00:35, , 28F
base object來減少出錯機率, 不過 this 變右值我記得
02/08 00:35, 28F
→
02/08 00:35, , 29F
N2439 有提到
02/08 00:35, 29F
→
02/08 00:39, , 30F
可以參考 N2377
02/08 00:39, 30F
→
02/08 00:46, , 31F
呣, 看來VC10還沒實裝 ... N2377 的意思應該是當實體
02/08 00:46, 31F
→
02/08 00:46, , 32F
可被推導成右值時, 就喚起修飾為 rvalue instance 的
02/08 00:46, 32F
→
02/08 00:47, , 33F
版本吧? 如果是這樣的話還滿實用的
02/08 00:47, 33F
→
02/08 01:09, , 34F
gcc 也還沒實裝 ... 我看等它們都實裝了我再跟進好了
02/08 01:09, 34F
→
02/08 01:09, , 35F
雖然可能要等上一年半載 ...
02/08 01:09, 35F
→
02/08 03:20, , 36F
c++ 真的變的好恐怖...
02/08 03:20, 36F
→
02/08 15:28, , 37F
坦白說這樣還是要寫很多重載版本啊= =
02/08 15:28, 37F
推
02/08 22:47, , 38F
不不, C++一直都很恐怖....(抖~_~)
02/08 22:47, 38F
→
02/09 02:50, , 39F
同意樓上，C++越學越覺得我什麼都不會...
02/09 02:50, 39F
→
02/09 02:51, , 40F
這篇文章我都看不懂 orz
02/09 02:51, 40F
‣ 更多 legnaleurc 的文章
文章代碼(AID): #1DJ-t0Go (C_and_CPP)
C_and_CPP 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 legnaleurc 的文章
文章代碼(AID): #1DJ-t0Go (C_and_CPP)