高分,请关注STL的效率问题!

headman 2004-08-24 11:57:11
大家一起来谈谈STL的效率问题。

这里我举个例子,STL中的string,比我们自己来直接操作char[],效率绝对是后面的高(除非是新手写的char[]的操作算法)。

我觉得STL为了其通用性必定会牺牲一些效率。

大家的看法呢?在一些高效率的程序中,你们还是用STL吗?还是自己封装?(我在公司使用的map就是自己用多叉树封装的,用char*作key,效率很高)
...全文
427 19 打赏 收藏 转发到动态 举报
写回复
用AI写文章
19 条回复
切换为时间正序
请发表友善的回复…
发表回复
jasn 2004-08-26
  • 打赏
  • 举报
回复
string在分配内存时是从内存池中取得所需要的内存的,可以防止内存碎片。如果有一天你把这些东西都做好的你会发现你的程序比STL更慢!!!!!!
jasn 2004-08-26
  • 打赏
  • 举报
回复
自已写char[]会在内存的操作上造成许多麻烦,不小心还会有许多罗辑上的问题。
string的引用记数并不完全不好。
Wolf0403 2004-08-26
  • 打赏
  • 举报
回复
>> string 是异常安全的,char*可以吗
是吗?STL-port 官方文档都没敢说这个大话。。

>> string 内存分配是由特定alloc完成的,效率快,空间耗费小,char*可以吗
去看看 <allocator>,标准 allocator 根本就是对 new/delete 的封装

>> string 有大量的相关专家精心打造的算法,char*可以吗
譬如?

>> 只有特定很少的情况下,需要自己写一点专用的代码
>> 例如只有固定的几个元素的数祖没必要去用vector
精辟。STL 不是拿来滥用的。

>> 99。999%的人写的代码跟STL相比只是二流水平
Oh, really?

>> 妄自尊大,对于STL的性能吹毛求疵,可笑啊可笑
唔~

=====================================

STL 里面最没有效率、实现最差的一个类就是 std::string。它跟 char * 或者 java.lang.String 或者 C# 的 System.String 都没有可比性。一层该死的封装隔绝了所有的灵活性;没有字符串池、没有写时拷贝,效率不会高;同时它也放弃了线程安全(STL 里面始终没有试图加入真正的多线程支持,整个 STL 乃至标准库都如此)。它在给初级程序员提供方便的同时牺牲了太多。这也是为什么几乎每个 C++ 框架都提供自己的 string 的原因吧。

要看 STL,看看容器、迭代起、操作器、函数对象,领会一下 STL 里面的先进思想——不要在这些细枝末节上面纠缠不清
xiaonian_3654 2004-08-26
  • 打赏
  • 举报
回复
有的时候不是STL效率低,而是我们不正确的使用造成的
白杨_baiy-cn 2004-08-26
  • 打赏
  • 举报
回复
=================================
...bastring.h
charT* data () { return reinterpret_cast<charT *>(this + 1); }
charT& operator[] (size_t s) { return data () [s]; }

从这里看,operator[]的调用应该是没什么太大区别的。
=================================
影子兄你看的是GCC的STL库吧?请你看清楚,你贴上来这段是private成员,你还是再去看看它的public版operator[]是怎么实现的吧。再说你为啥不想想如果operator[]真这么实现的话,如何做到写时copy呢?

=================================
string 是异常安全的,char*可以吗
string 内存分配是由特定alloc完成的,效率快,空间耗费小,char*可以吗
string 有大量的相关专家精心打造的算法,char*可以吗
只有特定很少的情况下,需要自己写一点专用的代码
例如只有固定的几个元素的数祖没必要去用vector
=================================
我们讨论的是char[],8是char* ^_^
stl的allocator和get_temporary_buffer都是用malloc分配内存的,比char*快?怎么说?

不过stl还是应该尽量用的,无论代码质量、算法的丰富性和效率都是很不错的。
FlyindanceDDr 2004-08-26
  • 打赏
  • 举报
回复
BS说: char[]是c的风格, string才是c++...
headman 2004-08-25
  • 打赏
  • 举报
回复
这么说你们使用STL后的程序的效率还是挺高的,对吗?
sandrowjw 2004-08-25
  • 打赏
  • 举报
回复
实际上还是要看怎么用的吧,有时候用rope比string和char[]更加好哪!

我也挺喜欢用char[]的,虽然代码有点不干净,但是效率高,控制权大。
alever513 2004-08-25
  • 打赏
  • 举报
回复
呵呵,目前我是写不出那么高效的算法---只不过有时候看着大把的空间给吃了,有点心痛
---
我只会在算法太复杂的情况下考虑用STL来节省代码量 ~ 而且简单的东西没必要用STL的
hcj2002 2004-08-25
  • 打赏
  • 举报
回复
在考虑了通用性后,效率方面肯定有所牺牲,但总体来说,效率还可以
headman 2004-08-25
  • 打赏
  • 举报
回复
上面的老兄不要激动。
一个初用STL的人不可能知道那么多。
所以这里大家只是探讨!

谢谢你告诉我们你对于STL的看法。

我的看法是,任何库在选取效率和使用性、功能性等因素折衷的情况下,效率都会有所牺牲。
梧桐168 2004-08-25
  • 打赏
  • 举报
回复
string 是异常安全的,char*可以吗
string 内存分配是由特定alloc完成的,效率快,空间耗费小,char*可以吗
string 有大量的相关专家精心打造的算法,char*可以吗
只有特定很少的情况下,需要自己写一点专用的代码
例如只有固定的几个元素的数祖没必要去用vector

99。999%的人写的代码跟STL相比只是二流水平
妄自尊大,对于STL的性能吹毛求疵,可笑啊可笑
白杨_baiy-cn 2004-08-24
  • 打赏
  • 举报
回复
===============================
差不多的。string里面本身就是一块char buf[]来实现的。
===============================
因为用了引用计数和写时拷贝,所以还是差一点啦,比如非const的operator[]就比char[]慢很多啦。

而由于C++是根据对象的const类型,而不是调用环境选择方法的const或非cosnt版本的,所以大部分情况用到的都是非const的operator。
DentistryDoctor 2004-08-24
  • 打赏
  • 举报
回复
效率损失都在于一些C++的语法因素,具体从算法的效率,一般人是无法与STL的那些大师相比的。有STL不用,除非特别的需要,否则自己写这些类确实是明智的。
白杨_baiy-cn 2004-08-24
  • 打赏
  • 举报
回复
string是个比较特殊的类,效率不太可能达到char[]。那些容器类和算法的效率还是蛮高的。

我觉得需要对某些情况特别优化也应当优先考虑从某个容器类专门化一个版本,最起码是写一个符合STL接口规范的新容器。这样做的好处是很多的。
rwdx 2004-08-24
  • 打赏
  • 举报
回复
up
pacman2000 2004-08-24
  • 打赏
  • 举报
回复
差不多的。string里面本身就是一块char buf[]来实现的。
pacman2000 2004-08-24
  • 打赏
  • 举报
回复
...bastring.h
charT* data () { return reinterpret_cast<charT *>(this + 1); }
charT& operator[] (size_t s) { return data () [s]; }

从这里看,operator[]的调用应该是没什么太大区别的。

如果追求效率的话,汇编比C强多了!
freefalcon 2004-08-24
  • 打赏
  • 举报
回复
我觉得STL为了其通用性必定会牺牲一些效率。

——这在某些场合是显然的,但也不是所有的都如此,因为很多工作都是编译期完成的

24,854

社区成员

发帖
与我相关
我的任务
社区描述
C/C++ 工具平台和程序库
社区管理员
  • 工具平台和程序库社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧