15,447
社区成员
发帖
与我相关
我的任务
分享STL的算法大家平时用的多吗？我感觉很像鸡肋，不知道大家有同感吗？
在写STL的时候，我也就是把它作为一个代替array的东西，对各个容器的选用当然也知道。但是STL里面有些古怪的东西，感觉其实没有什么用处?比如functor(function object),我就很少使用而且我喜欢使用for loop而不是for_each，copy这些算法.原因是for loop很直观，而且不需要自己在外面单独写一个function object,里面的逻辑可以自己很轻松的控制,也很好看懂.for_each,copy,transform这些感觉就像鸡肋,很多的时候并不好用，而且很容易出错.比如看有些人说什么高手用STL都不用forloop,但是我曾经想把自己的程序中的所有涉及STL容器的for loop都换成for_each等类似的写法,感觉非常非常的麻烦.functor不就是有一点内联的优势吗，但是有时候换过去感觉得不偿失.还有STL中的很多内置functor都不能满足需要，经常需要自己写，出来的代码非常不符合常规思路,所以我感觉functor这个东西真是很不实用.不知道大家在实际的编程中有使用functor吗?都是怎么用的?搞这么艰苦的语法,有用吗?大家真的用的多吗？
...全文
请发表友善的回复…
发表回复
lidongri 2008-07-14
- 打赏
- 举报
其实LZ不太对
问题就在于你对stl的期望太高了
stl不是万能的
他只包含了一些常用的算法，说白了就是造车轮频率最多的一些算法
比如我们自己创造或自己项目中使用的算法，stl里就不一定有
这很正常
还有，作为一个common的东西必然会有一定的性能或其他损失
但是stl做的已经很好了，至少他的效率没有因为通用性而损失很多
什么东西都不是万能的，万能的是你的双手。。。。
问题就在于你对stl的期望太高了
stl不是万能的
他只包含了一些常用的算法，说白了就是造车轮频率最多的一些算法
比如我们自己创造或自己项目中使用的算法，stl里就不一定有
这很正常
还有，作为一个common的东西必然会有一定的性能或其他损失
但是stl做的已经很好了，至少他的效率没有因为通用性而损失很多
什么东西都不是万能的，万能的是你的双手。。。。
laomai 2008-07-13
- 打赏
- 举报
呵呵，路过，旁观。
richbirdandy 2008-07-13
- 打赏
- 举报
[Quote=引用 64 楼 richbirdandy 的回复:]
单单内存池分配在很多地方都能借鉴
[/Quote]
厄 这个好象是sgi版本里才有的
单单内存池分配在很多地方都能借鉴
[/Quote]
厄 这个好象是sgi版本里才有的
richbirdandy 2008-07-13
- 打赏
- 举报
单单内存池分配在很多地方都能借鉴
xjywc 2008-07-13
- 打赏
- 举报
崇拜一下，路过留声。
Oversense 2008-07-12
- 打赏
- 举报
我也觉得为了 for_each 专门写一个 functor ，不爽
其实 本质上我是觉得把代码分得过于细碎，并不好
而且在类里面套一个类，我也不怎么写，因为觉得怎么缩进，都不好
其实 本质上我是觉得把代码分得过于细碎，并不好
而且在类里面套一个类，我也不怎么写，因为觉得怎么缩进，都不好
wfh_178 2008-07-12
- 打赏
- 举报
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法，什么适配器啊，仿函数啊，参数绑定啊，我感觉就没遇到过。也许，STL算法对设计算法的人应该是最实用的。:-)
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法，什么适配器啊，仿函数啊，参数绑定啊，我感觉就没遇到过。也许，STL算法对设计算法的人应该是最实用的。:-)
r_swordsman 2008-07-12
- 打赏
- 举报
[Quote=引用 61 楼 wfh_178 的回复:]
引用 59 楼 mathe 的回复:
引用 54 楼 wfh_178 的回复:
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法…
[/Quote]
呵呵...我可不会用STL....但我不觉得没用
引用 59 楼 mathe 的回复:
引用 54 楼 wfh_178 的回复:
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法…
[/Quote]
呵呵...我可不会用STL....但我不觉得没用
wfh_178 2008-07-12
- 打赏
- 举报
[Quote=引用 59 楼 mathe 的回复:]
引用 54 楼 wfh_178 的回复:
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法，什么适配器啊，仿函数啊，参…
[/Quote]
STL算法对设计STL算法的人应该是最实用？:-)
[Quote=引用 60 楼 r_swordsman 的回复:]
引用楼主 wfh_178 的帖子:
在写STL的时候，我也就是把它作为一个代替array的东西，对各个容器的选用当然也知道。但是STL里面有些古怪的东西，感觉其实没有什么用处?比如functor(function object),我就很少使用而且我喜欢使用for loop而不是for_each，copy这些算法.原因是for loop很直观，而且不需要自己在外面单独写一个function object,里面的逻辑可以自己很轻松的控制,也很好看懂.for_each,copy,transform这些感觉就像鸡肋,很…
[/Quote]
我不是不会使用，我是发现实际项目中能用到STL通用算法的地方非常非常少。这个帖子也不是讨论如何使用的，是想看看STL的通用算法部分，我们的高手们是如何在日常的工作中采用来facilitate我们的开发的。上面我说“也许，STL算法对设计算法的人应该是最实用的。:-)”，其实想想，实际的项目中，到了真正写算法的时候，又真正谁会去用STL的？游戏里面最简单的a*寻路，碰撞探测等，你能想象STL算法来写？呵呵。所以请楼上，说说你平时都怎么使用仿函数，适配器等的，在什么情况下，不然我认为你也是纸上谈兵之人而已。
引用 54 楼 wfh_178 的回复:
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法，什么适配器啊，仿函数啊，参…
[/Quote]
STL算法对设计STL算法的人应该是最实用？:-)
[Quote=引用 60 楼 r_swordsman 的回复:]
引用楼主 wfh_178 的帖子:
在写STL的时候，我也就是把它作为一个代替array的东西，对各个容器的选用当然也知道。但是STL里面有些古怪的东西，感觉其实没有什么用处?比如functor(function object),我就很少使用而且我喜欢使用for loop而不是for_each，copy这些算法.原因是for loop很直观，而且不需要自己在外面单独写一个function object,里面的逻辑可以自己很轻松的控制,也很好看懂.for_each,copy,transform这些感觉就像鸡肋,很…
[/Quote]
我不是不会使用，我是发现实际项目中能用到STL通用算法的地方非常非常少。这个帖子也不是讨论如何使用的，是想看看STL的通用算法部分，我们的高手们是如何在日常的工作中采用来facilitate我们的开发的。上面我说“也许，STL算法对设计算法的人应该是最实用的。:-)”，其实想想，实际的项目中，到了真正写算法的时候，又真正谁会去用STL的？游戏里面最简单的a*寻路，碰撞探测等，你能想象STL算法来写？呵呵。所以请楼上，说说你平时都怎么使用仿函数，适配器等的，在什么情况下，不然我认为你也是纸上谈兵之人而已。
r_swordsman 2008-07-12
- 打赏
- 举报
[Quote=引用楼主 wfh_178 的帖子:]
在写STL的时候，我也就是把它作为一个代替array的东西，对各个容器的选用当然也知道。但是STL里面有些古怪的东西，感觉其实没有什么用处?比如functor(function object),我就很少使用而且我喜欢使用for loop而不是for_each，copy这些算法.原因是for loop很直观，而且不需要自己在外面单独写一个function object,里面的逻辑可以自己很轻松的控制,也很好看懂.for_each,copy,transform这些感觉就像鸡肋,很多的时候并不好用，而且很容…
[/Quote]
当你认为某样东西没用时，只能说明你还不会使用
在写STL的时候，我也就是把它作为一个代替array的东西，对各个容器的选用当然也知道。但是STL里面有些古怪的东西，感觉其实没有什么用处?比如functor(function object),我就很少使用而且我喜欢使用for loop而不是for_each，copy这些算法.原因是for loop很直观，而且不需要自己在外面单独写一个function object,里面的逻辑可以自己很轻松的控制,也很好看懂.for_each,copy,transform这些感觉就像鸡肋,很多的时候并不好用，而且很容…
[/Quote]
当你认为某样东西没用时，只能说明你还不会使用
mathe 2008-07-12
- 打赏
- 举报
[Quote=引用 54 楼 wfh_178 的回复:]
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法，什么适配器啊，仿函数啊，参数绑定啊，我感觉就没遇到过…
[/Quote]
我觉得其实很多functional实现了是因为STL内部事先某些容器的需要，只是同时提供了用户使用的接口而已。
vitin说得真好，我很赞同。
STL的容器部分我觉得非常实用，比如string,vector,map这些给编程带来相当的便利,可以说无法避免。通用算法部分，我承认他们设计都很精巧，但是实用性大不如前者，而且学习成本太高，不是说我觉得太难，我觉得实用性不强，我想这应该是大多数人的事实。目前公司这个项目上百万行代码，90年代就开始在写的，我发现几乎没用到什么STL通用算法，什么适配器啊，仿函数啊，参数绑定啊，我感觉就没遇到过…
[/Quote]
我觉得其实很多functional实现了是因为STL内部事先某些容器的需要，只是同时提供了用户使用的接口而已。
mathe 2008-07-12
- 打赏
- 举报
[Quote=引用 49 楼 jackzhhuang 的回复:]
我有时会使用STK，我对STL还是比较了解的，应该说STL有时可以大大减低我的工作量。
比如排序，查找，还有哈希表（虽然还不属于标准）这些时不时会用。
删除有时也会用，可以说，STL效率高，可读性强。
但不排除一些“高手”写出晦涩难懂的STL代码还以此自以为水平高。
另外我不太习惯类名首字母使用小写，所以我总是typedef
[/Quote]
比较同意这个观点。同我习惯比较类似。
此外像模板类之类的东西，自己还是尽量少用的好，除非真得发现某部分代码需要大量的关于不同数据类型的重用。如果是这样，也应该尽量将这部分代码同其他部分分开设计。
我有时会使用STK，我对STL还是比较了解的，应该说STL有时可以大大减低我的工作量。
比如排序，查找，还有哈希表（虽然还不属于标准）这些时不时会用。
删除有时也会用，可以说，STL效率高，可读性强。
但不排除一些“高手”写出晦涩难懂的STL代码还以此自以为水平高。
另外我不太习惯类名首字母使用小写，所以我总是typedef
[/Quote]
比较同意这个观点。同我习惯比较类似。
此外像模板类之类的东西，自己还是尽量少用的好，除非真得发现某部分代码需要大量的关于不同数据类型的重用。如果是这样，也应该尽量将这部分代码同其他部分分开设计。
执假以为真 2008-07-12
- 打赏
- 举报
STL好像有个缺点吧？就是很难debug。
我也是听高手说的，自己没有实验过。知道的人进来说说，如果只是对STL用的很熟，而没有调试过很多包含了STL程序的人，就不用发表意见了。没有调查就没有发言权嘛。
我也是听高手说的，自己没有实验过。知道的人进来说说，如果只是对STL用的很熟，而没有调试过很多包含了STL程序的人，就不用发表意见了。没有调查就没有发言权嘛。
Oversense 2008-07-12
- 打赏
- 举报
不过如果用 BOOST_FOREACH 也可以搞定不少问题
jackzhhuang 2008-07-11
- 打赏
- 举报
我有时会使用STK，我对STL还是比较了解的，应该说STL有时可以大大减低我的工作量。
比如排序，查找，还有哈希表（虽然还不属于标准）这些时不时会用。
删除有时也会用，可以说，STL效率高，可读性强。
但不排除一些“高手”写出晦涩难懂的STL代码还以此自以为水平高。
另外我不太习惯类名首字母使用小写，所以我总是typedef
比如排序，查找，还有哈希表（虽然还不属于标准）这些时不时会用。
删除有时也会用，可以说，STL效率高，可读性强。
但不排除一些“高手”写出晦涩难懂的STL代码还以此自以为水平高。
另外我不太习惯类名首字母使用小写，所以我总是typedef
wfh_178 2008-07-11
- 打赏
- 举报
[Quote=引用 46 楼 WingForce 的回复:]
引用 44 楼 wfh_178 的回复:
谢天谢地，终于调试通过最后的版本的了。
STL对non-type parameter要求必须是编译期常数，TNND!
这并不是STL的要求，而是template本身的要求
好吧。。。
我费劲脑筋也只能想到copy算法可以使用trait技术分辨出对象的拷贝构造函数是否trivial的，从而对其直接使用memmove而不是逐个赋值这一个例子来说明STL算法比直接循环效率要高的优势
[/Quote]
那个是STL里面设计很精致的地方,但如果是non-trivial的拷贝构造函数效率又一样了。对了，copy好像是用的赋值运算符判断的，不是拷贝构造函数。
呵呵，发现Linus炮轰C++的时候说的关于STL部分
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
引用 44 楼 wfh_178 的回复:
谢天谢地，终于调试通过最后的版本的了。
STL对non-type parameter要求必须是编译期常数，TNND!
这并不是STL的要求，而是template本身的要求
好吧。。。
我费劲脑筋也只能想到copy算法可以使用trait技术分辨出对象的拷贝构造函数是否trivial的，从而对其直接使用memmove而不是逐个赋值这一个例子来说明STL算法比直接循环效率要高的优势
[/Quote]
那个是STL里面设计很精致的地方,但如果是non-trivial的拷贝构造函数效率又一样了。对了，copy好像是用的赋值运算符判断的，不是拷贝构造函数。
呵呵，发现Linus炮轰C++的时候说的关于STL部分
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
Vitin 2008-07-11
- 打赏
- 举报
关于效率、正确性、可维护性。
从效率上说，STL版本只执行一次 PanesVec.end()、x - SB_IMG_WIDTH，比loop版本效率要高一些。当然，这有个适用性问题，在终止条件或其他一些冗余操作的代价并不大时，STL效率优势就没有体现出来。另外，loop版本也可以删除冗余操作，但通常不会去想到要在这样做。
因此，我觉得效率方面的区别在于：
1、STL尽量降低效率上的额外代价（如通过内联函数等方式），即虽然没有更好，但不至于更坏；
2、STL令使用者将注意力集中到算法上，从而很容易地分辨出冗余的操作。
3、STL收录的算法都经过精心设计，会比编程初学者写的算法要好一些（包括效率）。
正确性。正确性的前提是把握语言特性。当你熟练STL时，你可以做得和其他特性（如loop）同样好。STL并不难，只是需要去熟悉它。
可维护性。这是STL的强大之处，至少包括以下几点：
1、因为GP的存在，类型不同不再是问题，对于不同类型只需编写一个版本；
2、将一个大的算法分解成多个小算法，焦点在于算法的组合和新的小算法，而不是每次设计一个冗长的大算法；
3、粒度是算法和容器，而不是语句和内存块，提高了抽象层次。
以上这些都提高了可维护性；并且，它也有利于提高正确性。
当然，（对于具体的情况，如一个特定项目，）STL 也不是必须使用的。如果在项目中，某个算法只被使用一次，那么就不必设计成独立函数；如果某个算法只用于一种具体类型，那么就不必设计成泛型算法。
GP、甚至OO，在不需要的时候就可以不使用（比如有时候用C语言也很好）；特别地，在不适合的时候就不应该使用。
但是，在适合的、需要的场合，GP和OO就可以发挥它们的特长了。
从效率上说，STL版本只执行一次 PanesVec.end()、x - SB_IMG_WIDTH，比loop版本效率要高一些。当然，这有个适用性问题，在终止条件或其他一些冗余操作的代价并不大时，STL效率优势就没有体现出来。另外，loop版本也可以删除冗余操作，但通常不会去想到要在这样做。
因此，我觉得效率方面的区别在于：
1、STL尽量降低效率上的额外代价（如通过内联函数等方式），即虽然没有更好，但不至于更坏；
2、STL令使用者将注意力集中到算法上，从而很容易地分辨出冗余的操作。
3、STL收录的算法都经过精心设计，会比编程初学者写的算法要好一些（包括效率）。
正确性。正确性的前提是把握语言特性。当你熟练STL时，你可以做得和其他特性（如loop）同样好。STL并不难，只是需要去熟悉它。
可维护性。这是STL的强大之处，至少包括以下几点：
1、因为GP的存在，类型不同不再是问题，对于不同类型只需编写一个版本；
2、将一个大的算法分解成多个小算法，焦点在于算法的组合和新的小算法，而不是每次设计一个冗长的大算法；
3、粒度是算法和容器，而不是语句和内存块，提高了抽象层次。
以上这些都提高了可维护性；并且，它也有利于提高正确性。
当然，（对于具体的情况，如一个特定项目，）STL 也不是必须使用的。如果在项目中，某个算法只被使用一次，那么就不必设计成独立函数；如果某个算法只用于一种具体类型，那么就不必设计成泛型算法。
GP、甚至OO，在不需要的时候就可以不使用（比如有时候用C语言也很好）；特别地，在不适合的时候就不应该使用。
但是，在适合的、需要的场合，GP和OO就可以发挥它们的特长了。
WingForce 2008-07-11
- 打赏
- 举报
[Quote=引用 48 楼 wfh_178 的回复:]
呵呵，发现Linus炮轰C++的时候说的关于STL部分
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
[/Quote]
我觉得Linus一直在做操作系统，经验和习惯使他不是非常能接受类似c++，java这类语言吧
呵呵，发现Linus炮轰C++的时候说的关于STL部分
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
[/Quote]
我觉得Linus一直在做操作系统，经验和习惯使他不是非常能接受类似c++，java这类语言吧
珍惜生命远离CPP 2008-07-11
- 打赏
- 举报
对STL不满的话完全可以不用，又没有人非逼你得用。
thinke365 2008-07-11
- 打赏
- 举报
[Quote=引用 7 楼 akirya 的回复:]
引用 1 楼 taodm 的回复:
楼主，写一段从一个vector或者list里删除所有值为x的元素的代码贴出来吧。
这个用stl写也就1行。
[/Quote]
呵呵，这样可以极大地提升生产力啊，但前提是要对这些API滚瓜烂熟。。。
引用 1 楼 taodm 的回复:
楼主，写一段从一个vector或者list里删除所有值为x的元素的代码贴出来吧。
这个用stl写也就1行。
[/Quote]
呵呵，这样可以极大地提升生产力啊，但前提是要对这些API滚瓜烂熟。。。
加载更多回复（47）
