不是所有的状况都是这样
但很多时候用 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
: 很可能就改回不去了