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

Re: [問題] break的問題

看板C_and_CPP (C/C++)作者 (眠月)時間11年前 (2014/06/28 23:01), 編輯推噓10(10推 0噓 21→)
留言31則, 11人參與, 最新討論串5/6 (看更多)
不是所有的狀況都是這樣 但很多時候用 range 會有好處 可讀性比較高、程式碼比較短、複用性也比較好 可以看敝人這篇關於 boost range adaptor 的範例 https://www.ptt.cc/bbs/C_and_CPP/M.1302453243.A.432.html 試想如果不用 range 的話寫起來會麻煩很多 而且讀程式碼的人需要額外付出心思才能看懂原作者的意圖 template 速度慢這件事情，不太可能 我唯一能想到的就是你忘記開最佳化 你要不要再認真作一次 benchmark？ 至於 boost 很肥這個問題 你應該是指之前你想要用 boost::graph 但切不出來的事情？ 其實你一開始想要把 boost 的 source 放進 project 的 repo 就是一個錯誤的選擇 除非是很特別的狀況，不然 boost 的 source 應該是被視作「開發環境」的一部分 一般沒有 project 會想要把 boost 放進自己的 repo 裡面 你想想看就知道，我電腦裡面這麼多 project，明明大家用的都同一個 boost 如果每個 project 都自己一份 boost，那還得了？ 大家都是直接安裝一份 boost 在自己的工作環境上 要用到的 boost 的人就隨著設定的 PATH 去 include 就像正常狀況沒有人會把 STL 放進自己的 repo 一樣 而 boost 本身交相授粉不易切割這點，通常是被視作 boost 品質優良的象徵 因為程式碼寫出來就是要讓人用的，就是因為寫的好才會多被使用 但回到原點，以樓主這個 case 來說 改成用 range 以後，程式碼從 9 行膨脹到 20 行，而且也沒有比較好讀 XD 板主大大的寫法反而變成有點 over design 了是真的 但如果平常習慣這種寫法 才有可能會邁向本文最上面講的 平常就使用 range 來加速開發跟提高可讀性的階段 就當作是一種練習也好 事實上這是一個趨勢了 很多語言都已經開始往 range 的方向移動 理論上也沒錯，如果我要處理的對象是元素，那我直接 iterate 元素就好 幹麻去 iterate 一個 iterator 來存取元素？ 多一步就是多一個錯誤的機會… ※ 引述《iamstudent (stu)》之銘言： : 關於版主提到的 : for loop應該改用樣板演算法去做 : 我有不少想法希望討論 : 關於template處理迴圈 : 有時候感覺可讀性其實沒有提高多少 : 傳統的for loop一樣非常簡單易懂 : 反而template並不是所有人都相當熟悉 : 如果迴圈內的工作比較複雜時 : 那麼把內部的工作抽出成為函數 : 用迴圈呼叫該工作函數即可 : 如果迴圈內處理的工作並不複雜 : 那麼template感覺上反而要寫更多東西 : 會有點像是強迫寫一個小函數 : 如果多起來就相當令人討厭 : 尤其是當該工作內容量根本就沒有寫成函數的價值時 : 會覺得這樣作似乎非常多餘 : 除了工作速度之外 : 執行速度是否有所提昇也相當令人質疑 : 以往的測試結果是template版本通常都比較慢 : 最後是boost : 說實話，有人非常討厭它 : 以前接計畫時 : 就有主管表示不要用boost : 我自己使用之後也有些經驗 : 對於規模不大的程式 : boost感覺上非常肥 : 而且一直無法只把想要的功能抽離出來 : 裡面的檔案互相糾纏引用到非常複雜 : 成為一塊巨大而難以分割的整體 : 最討厭的一點是 : 程式一旦用了boost : 很可能就改回不去了 -- To iterate is human, to recurse, divine. 遞迴只應天上有, 凡人該當用迴圈. 　 L. Peter Deutsch -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.70.183.170 ※ 文章網址: http://www.ptt.cc/bbs/C_and_CPP/M.1403967696.A.604.html
→
06/28 23:19, , 1F
這時候不得不說 ruby 真的包裝得很棒！
06/28 23:19, 1F
→
06/28 23:51, , 2F
Deploy 的時候還是很肥啊, 除非你要靜態編譯
06/28 23:51, 2F
→
06/29 00:02, , 3F
說template速度慢也許是誤把compile慢跟runtime慢搞混了
06/29 00:02, 3F
推
06/29 13:24, , 4F
等等！這邊我要回一下，我指的是執行速度
06/29 13:24, 4F
→
06/29 13:24, , 5F
我不會到分不清編譯速度與執行速度
06/29 13:24, 5F
→
06/29 13:25, , 6F
而且我也很清楚要開最佳化，用debug模式測試根本無意義
06/29 13:25, 6F
→
06/29 13:27, , 7F
以前我在VS2005上測試過三種掃過動態配置空間的方法
06/29 13:27, 7F
→
06/29 13:29, , 8F
結果最快的是指標遞增，loop i與iterator寫法都比較慢
06/29 13:29, 8F
→
06/29 13:29, , 9F
另外還有一個也是很明確肯定不會比較快的case
06/29 13:29, 9F
→
06/29 13:30, , 10F
使用template作長向量加法，然後不產生暫時物件
06/29 13:30, 10F
→
06/29 13:31, , 11F
在C++ Template全覽這本書裡面可以找到它的程式碼
06/29 13:31, 11F
→
06/29 13:32, , 12F
結果也是template用了反而更慢，作者也有提到這點
06/29 13:32, 12F
→
06/29 13:33, , 13F
不是所有東西都搬到編譯期就有辦法被最佳化
06/29 13:33, 13F
→
06/29 13:37, , 14F
目前的編譯器已經很強了，但對於template似乎仍有不足
06/29 13:37, 14F
推
06/29 17:03, , 15F
唉唷，template 何辜。其實是我有強迫症啦！(超過兩層
06/29 17:03, 15F
推
06/29 17:03, , 16F
的迴圈我看了會頭暈) xD 看不懂 STL Algorithms 可能
06/29 17:03, 16F
推
06/29 17:03, , 17F
來自石器時代？我能接受的最低限度是 range-based for
06/29 17:03, 17F
推
06/29 17:03, , 18F
，有時為了省初始化的行數才會勉強用 for，不然都是 w
06/29 17:03, 18F
推
06/29 17:03, , 19F
hile。看個人取捨啦，效能真的有瓶頸時還是得往回改。
06/29 17:03, 19F
→
06/29 17:04, , 20F
啊啊 手機用到連讚拍謝，不是耍特權
06/29 17:04, 20F
→
06/30 08:50, , 21F
vs2005...............
06/30 08:50, 21F
→
06/30 11:20, , 22F
我很不習慣用while 看完我覺得應該要改掉...
06/30 11:20, 22F
→
06/30 12:24, , 23F
for(;;) and while(1), dochi!
06/30 12:24, 23F
→
06/30 12:25, , 24F
2005已經是十年前的古董了 :D
06/30 12:25, 24F
推
07/01 13:21, , 25F
while(true) 因為藍藍的比較好看
07/01 13:21, 25F
推
07/02 00:05, , 26F
PUSH
07/02 00:05, 26F
推
07/03 09:40, , 27F
還在用古董2005 +1.... =__=;
07/03 09:40, 27F
→
07/03 09:41, , 28F
岔話題 有強迫症的人寫程式很辛苦 要把別人的寫法全部
07/03 09:41, 28F
→
07/03 09:42, , 29F
先在style上改成自己的風格 然後是變數命名 ....
07/03 09:42, 29F
→
07/03 09:43, , 30F
所有的堅持都是編譯器忽略的東西
07/03 09:43, 30F
推
07/03 21:12, , 31F
@donkeychen : 不過 team work 的專案似乎較不允許這麼做
07/03 21:12, 31F
‣ 更多 yoco315 的文章
文章代碼(AID): #1JhjZGO4 (C_and_CPP)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 5 之 6 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共6篇)
C_and_CPP 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 yoco315 的文章
文章代碼(AID): #1JhjZGO4 (C_and_CPP)