Re: [問題] break的問題

[yoco315 (眠月)]

不是所有的狀況都是這樣
但很多時候用 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
→ diabloevagto:這時候不得不說 ruby 真的包裝得很棒！
→ uranusjr:Deploy 的時候還是很肥啊, 除非你要靜態編譯
→ Killercat:說template速度慢也許是誤把compile慢跟runtime慢搞混了
推 iamstudent:等等！這邊我要回一下，我指的是執行速度
→ iamstudent:我不會到分不清編譯速度與執行速度
→ iamstudent:而且我也很清楚要開最佳化，用debug模式測試根本無意義
→ iamstudent:以前我在VS2005上測試過三種掃過動態配置空間的方法
→ iamstudent:結果最快的是指標遞增，loop i與iterator寫法都比較慢
→ iamstudent:另外還有一個也是很明確肯定不會比較快的case
→ iamstudent:使用template作長向量加法，然後不產生暫時物件
→ iamstudent:在C++ Template全覽這本書裡面可以找到它的程式碼
→ iamstudent:結果也是template用了反而更慢，作者也有提到這點
→ iamstudent:不是所有東西都搬到編譯期就有辦法被最佳化
→ iamstudent:目前的編譯器已經很強了，但對於template似乎仍有不足
推 loveme00835:唉唷，template 何辜。其實是我有強迫症啦！(超過兩層
推 loveme00835:的迴圈我看了會頭暈) xD 看不懂 STL Algorithms 可能
推 loveme00835:來自石器時代？我能接受的最低限度是 range-based for
推 loveme00835:，有時為了省初始化的行數才會勉強用 for，不然都是 w
推 loveme00835:hile。看個人取捨啦，效能真的有瓶頸時還是得往回改。
→ loveme00835:啊啊 手機用到連讚拍謝，不是耍特權
→ yoco315:vs2005...............
→ KanoLoa:我很不習慣用while 看完我覺得應該要改掉...
→ Killercat:for(;;) and while(1), dochi!
→ Killercat:2005已經是十年前的古董了 :D
推 GoalBased:while(true) 因為藍藍的比較好看
推 elfkiller:PUSH
推 donkeychen:還在用古董2005 +1.... =__=;
→ donkeychen:岔話題 有強迫症的人寫程式很辛苦 要把別人的寫法全部
→ donkeychen:先在style上改成自己的風格 然後是變數命名 ....
→ donkeychen:所有的堅持都是編譯器忽略的東西
推 EdisonX:@donkeychen : 不過 team work 的專案似乎較不允許這麼做