[問題] C++ for loop 的 string 宣告

看板C_and_CPP作者 (安打星)時間13年前 (2012/03/17 19:39), 編輯推噓27(27推 0噓 58→)
留言85則, 17人參與, 最新討論串1/2 (看更多)
請問以下兩個寫法，是否在記憶體的使用方面，兩者有優劣之分嗎？ 兩者唯一的差別在於 path 宣告的位置不同，path 這個變數在 loop 之後也不會再用到。 我自己習慣用 (1)，先宣告起來放，不會在 loop 裡面重複宣告 可是從建構/解構的角度來看，是不是沒差別呢？ 補充一下，兩個都只是某個 function 裡面的 code而已 我的想法如下，煩請大大賜教。 (1) 先宣告的時候，呼叫了 default 建構子 loop 每跑一次，path 就做一次 "=" 的運算 "=" 運算的時候，若原本有資料，則會先呼叫解構子，之後再存入 上面這一行，是對的嗎？ @@? (2) loop 每跑一次，path 就先呼叫 default 再做 "=" 的運算，loop 結束則呼叫解構子 所以兩個根本沒什麼差，對嗎？ 先感謝大家 ^^ ----------------------------------------- (1) string path; for( ... ) { path = string("xxxx") + "zzzz"; ... if (xxx) return 1; } return 0; (2) for( ... ) { string path = staing("xxxx") + "zzzz"; ... if (xxx) return 1; } return 0; -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.139.52.202
→
03/17 19:50, , 1F
只要正常一點的編譯器應該都懂最佳化這種東西, 所以實務
03/17 19:50, 1F
→
03/17 19:51, , 2F
上應該不會有差別...
03/17 19:51, 2F
→
03/17 21:14, , 3F
如果是ctor和=差很多的奇怪class可能會有差別
03/17 21:14, 3F
→
03/17 21:17, , 4F
不負責測試的結果，2比1快，不論有沒有開O2，版本gcc4.4.5
03/17 21:17, 4F
→
03/17 21:18, , 5F
有人可以重做一下實驗嗎？我對於我的數據還滿懷疑的。
03/17 21:18, 5F
→
03/17 21:44, , 6F
gcc-4.3.4 on ideone.com
03/17 21:44, 6F
→
03/17 21:45, , 7F
03/17 21:45, 7F
→
03/17 21:45, , 8F
03/17 21:45, 8F
※ 編輯: SingleStar 來自: 220.139.52.202 (03/17 21:46)
→
03/17 21:50, , 9F
為什麼(2)會比較快呢？ 我以為是(1)比較快 @@
03/17 21:50, 9F
推
03/17 22:25, , 10F
(2) 其實是呼叫 copy constructor 而非 operator =
03/17 22:25, 10F
→
03/17 22:26, , 11F
它會將右邊 operator + 的回傳物件直接丟進去 path 的 ctor
03/17 22:26, 11F
→
03/17 22:26, , 12F
因此每一圈裡這 path 都是全新的 path
03/17 22:26, 12F
推
03/18 09:13, , 13F
照這 gcc 版本，大概 rvalue reference 有介入吧!?
03/18 09:13, 13F
→
03/18 09:14, , 14F
(1) 用 move assignment 比 (2) 用 move ctor 稍慢一小點
03/18 09:14, 14F
推
03/18 09:23, , 15F
剛用 VC2010 測，每次迴圈(1)比(2)得多進一次 move assign
03/18 09:23, 15F
推
03/18 11:56, , 16F
做=前不會先呼叫解構子吧
03/18 11:56, 16F
推
03/18 12:30, , 17F
不會 都還要做物件的operator=怎麼可能先解構
03/18 12:30, 17F
→
03/18 14:04, , 18F
我真的認為只有一個不好的語言才會搞出這麼多pitfall
03/18 14:04, 18F
推
03/18 14:07, , 19F
如果不是為了接手既有的code 誠心建議用新語言開發新東西
03/18 14:07, 19F
→
03/18 14:08, , 20F
就讓c++慢慢消失在歷史洪流中吧 plz!
03/18 14:08, 20F
→
03/18 14:14, , 21F
BTW我指的是c++而已 c是好語言阿!
03/18 14:14, 21F
推
03/18 15:23, , 22F
Java 也有 Puzzlers，也是個很壞的語言，嗯...
03/18 15:23, 22F
推
03/18 15:55, , 23F
那就用更先進的語言阿 樓上 覺得不好就換囉
03/18 15:55, 23F
→
03/18 16:14, , 24F
C++的確很多陷阱，不過把這個也算在陷阱裡...?
03/18 16:14, 24F
推
03/18 19:40, , 25F
這也是我想知道的問題之一，目前業界主流是什麼語言？
03/18 19:40, 25F
→
03/18 19:42, , 26F
雖然知道c++有不少陷阱，但要別人跟著換語言實在太難
03/18 19:42, 26F
→
03/18 19:43, , 27F
反過來，教別人避開c++的險境，好像也很沒說服力
03/18 19:43, 27F
推
03/18 19:47, , 28F
業界主流還是c++(ic design除外) 所以我只能說開發新東西
03/18 19:47, 28F
→
03/18 19:47, , 29F
時盡量用新的
03/18 19:47, 29F
→
03/18 19:48, , 30F
BTW 對於學通的人來說 換語言應該不是難事才對
03/18 19:48, 30F
→
03/18 20:24, , 31F
這個說法應該只適用於語言的基礎使用而已吧？
03/18 20:24, 31F
→
03/18 20:24, , 32F
實務上的軟體稍微有點規模，應該都不是從0寫起
03/18 20:24, 32F
→
03/18 20:26, , 33F
而這些基礎的部份往往不是換語言之後也能續用的
03/18 20:26, 33F
→
03/18 20:27, , 34F
函數庫、模組、跨專案可以再利用的程式...
03/18 20:27, 34F
→
03/18 20:28, , 35F
只要把開發的時間也納入成本，很可能是個絕對障礙
03/18 20:28, 35F
推
03/18 20:44, , 36F
所以我指的是完全的重新開發 如果你已經有了一大堆c++的
03/18 20:44, 36F
→
03/18 20:45, , 37F
lib要編譯進你的專案 那當然是沒得解
03/18 20:45, 37F
→
03/18 20:46, , 38F
不過如果能夠用別的方式和這些lib做整合而不用編進來
03/18 20:46, 38F
→
03/18 20:47, , 39F
又不犧牲太大效能的狀況下 還是可以考慮一下別的語言
03/18 20:47, 39F
推
03/18 20:52, , 40F
我覺的要評估的點很多 不能一概而論 但如果能不用c++最好
03/18 20:52, 40F
推
03/18 21:04, , 41F
C的問題超大 怎麼會是個好語言 XD
03/18 21:04, 41F
推
03/18 21:11, , 42F
樓上要不說明一下 願聞其詳
03/18 21:11, 42F
→
03/18 21:16, , 43F
17807、17810已經討論滿多了，語言不就是自己用習慣
03/18 21:16, 43F
→
03/18 21:16, , 44F
就好，這些不過就是工具，畢竟以後工作也不是自己選
03/18 21:16, 44F
→
03/18 21:16, , 45F
語言，老闆要用什麼就是用什麼啊
03/18 21:16, 45F
→
03/18 21:18, , 46F
所以這些討論是給要當老闆的人看的阿
03/18 21:18, 46F
→
03/18 21:22, , 47F
j大對c++怨念很深...
03/18 21:22, 47F
推
03/18 21:26, , 48F
我認為c++有其歷史上的階段性任務 而它也沒讓大家失望
03/18 21:26, 48F
→
03/18 21:28, , 49F
但是現在是向前走的時候了 有很多語言在c++上發展得更好用
03/18 21:28, 49F
→
03/18 21:29, , 50F
可以加快開發速度 提升系統安全 太多特性可以發揮
03/18 21:29, 50F
推
03/18 22:16, , 51F
我不是說C++萬能，而是只有C或C++能選時我傾向C++
03/18 22:16, 51F
→
03/18 22:21, , 52F
話說c++在寫oo上好像不是很直覺，不知道是否是我不太
03/18 22:21, 52F
→
03/18 22:21, , 53F
會寫...Orz
03/18 22:21, 53F
→
03/18 22:33, , 54F
樓上加強一下 ADT
03/18 22:33, 54F
推
03/18 22:38, , 55F
c++寫oo非常強勁 但最好避免某些pitfall 會讓日子好過一點
03/18 22:38, 55F
→
03/18 22:42, , 56F
http://0rz.tw/304P1 google的c++ style 可供參考
03/18 22:42, 56F
推
03/18 22:45, , 57F
有趣的是 你可以觀察一下 google禁止了多少c++的特色
03/18 22:45, 57F
推
03/19 10:00, , 58F
跟common practices不同的只有不要用exception，所以？
03/19 10:00, 58F
推
03/19 10:09, , 59F
沒錯啊 我們在寫的時候的common practice包括
03/19 10:09, 59F
→
03/19 10:10, , 60F
不要寫copy constructor, 不要operator overloading, pass
03/19 10:10, 60F
→
03/19 10:10, , 61F
by ref只能為 const, 不要用RTTI, 不要有default argument
03/19 10:10, 61F
→
03/19 10:10, , 62F
不要用c++ exception 不要用多重繼承, 不要用c++11, 不要
03/19 10:10, 62F
→
03/19 10:11, , 63F
用stream. 重點就在此 c++做了一堆會造成pitfall的東西
03/19 10:11, 63F
→
03/19 10:12, , 64F
導致大家最後都在用c++的子集 那何必咧
03/19 10:12, 64F
推
03/19 11:06, , 65F
他哪有說「不要」，他說的是「only when necessary」
03/19 11:06, 65F
推
03/19 11:15, , 66F
而且google style也不是全部都很有道理
03/19 11:15, 66F
→
03/19 11:16, , 67F
stream很難用沒錯，但printf更危險哩
03/19 11:16, 67F
推
03/19 13:05, , 68F
提供東西給你，要不要用都是選擇，這也能拿出來鞭，呵呵
03/19 13:05, 68F
推
03/19 13:25, , 69F
copy constr與operator=只會有三種case
03/19 13:25, 69F
→
03/19 13:25, , 70F
可以用default、需要手動改寫、不該使用要關掉
03/19 13:25, 70F
→
03/19 13:30, , 71F
也許他說的需要時是包含前面兩種，目的是要能看見
03/19 13:30, 71F
推
03/19 16:57, , 72F
就是這些選擇讓目前用c++寫的程式維護困難 也許樓上都是
03/19 16:57, 72F
→
03/19 16:58, , 73F
都是程式高手 都已經對c++瞭如指掌 所以可以在該用的地方
03/19 16:58, 73F
→
03/19 16:58, , 74F
使用正確的做法 問題是現實世界中 很難保證一個團隊中每
03/19 16:58, 74F
→
03/19 16:59, , 75F
個人都有這些基礎 我相信樓上各位一定都有遇過 要幫別人
03/19 16:59, 75F
→
03/19 17:00, , 76F
擦屁股的狀況 如果有更好的語言 能夠避免這種狀況 為何不
03/19 17:00, 76F
→
03/19 17:01, , 77F
用? c++包山包海的特性造成程式維護困難 不能鞭嗎?
03/19 17:01, 77F
推
03/19 19:01, , 78F
那個「更好的語言」實在很難輪到C來當
03/19 19:01, 78F
推
03/20 02:02, , 79F
D語言萬歲
03/20 02:02, 79F
→
03/20 02:02, , 80F
jackace大就靠你推D了　如果你需要一個更好維謢 更漂亮
03/20 02:02, 80F
→
03/20 02:03, , 81F
更先進的語言　歡迎用這個沒什麼人想用的D language..XD
03/20 02:03, 81F
→
03/21 12:15, , 82F
上面不瞭解誤會語言用法的 話還 說那麼多 真是無言
03/21 12:15, 82F
→
03/21 12:15, , 83F
誰跟你說不要用copy constructor 不要用非const ref...了?
03/21 12:15, 83F
→
03/21 12:16, , 84F
各種用法有不同的採用時機 google的標準也不是金科玉律
03/21 12:16, 84F
→
03/21 12:17, , 85F
學語言學了半套 結果話講的比誰都大聲 ...
03/21 12:17, 85F
‣ 更多 SingleStar 的文章
文章代碼(AID): #1FP7VaAD (C_and_CPP)
‣ 更多 SingleStar 的文章
文章代碼(AID): #1FP7VaAD (C_and_CPP)