64,659
社区成员
发帖
与我相关
我的任务
分享string的效率问题
不知道string的效率如何
现在有一个
char p[1024]的字符数组
不断将字符填入p
想用string的一些方法，于是
string aString=string(p);
string b=p.substr（1，10）
不知道这项是不是比自己在p上移动指针慢很多
现在有一个
char p[1024]的字符数组
不断将字符填入p
想用string的一些方法，于是
string aString=string(p);
string b=p.substr（1，10）
不知道这项是不是比自己在p上移动指针慢很多
...全文
请发表友善的回复…
发表回复
taodm 2007-07-05
- 打赏
- 举报
mLee79() 说说哪些地方有过多的临时对象的创建吧。对比相同情况下，字符数组是如何处理这些情况的呢？
loops 2007-07-05
- 打赏
- 举报
STL设计的时候是包含thread safe的目的吗？
我印象中STL是以高效为第一目的的。
我印象中STL是以高效为第一目的的。
mLee79 2007-07-05
- 打赏
- 举报
不是在于动态分配内存, 基于以前讨论标准的实现通常都用引用计数+COW实现, 但是在多线程/多CPU环境中是不安全的, 到现在已经基本被废止, 现在的实现通常都基于值语义, 导致过多的临时对象的创建...
loops 2007-07-05
- 打赏
- 举报
string高不高效，关键看怎么使用它了。
string低效主要还是在于动态分配内存，以及若干个成员函数的返回的是临时对象，而不是引用。而且自vc2005开始，相比vc6.0而言，我发现string的实现又进行了改变，对于处理少于8个字节的字符串，不用再动态分配内存。甚至还可以重写底层的allocator类。
总之，如果性能敏感的应用，如果应用得好，应该不比数组差。
string低效主要还是在于动态分配内存，以及若干个成员函数的返回的是临时对象，而不是引用。而且自vc2005开始，相比vc6.0而言，我发现string的实现又进行了改变，对于处理少于8个字节的字符串，不用再动态分配内存。甚至还可以重写底层的allocator类。
总之，如果性能敏感的应用，如果应用得好，应该不比数组差。
mLee79 2007-07-05
- 打赏
- 举报
string 高效倒是第一次听说, 据我所知道的 string && stream 是两个相当低效的玩意, 当然对一般的性能不敏感的应用倒是足够了 ...
loops 2007-07-05
- 打赏
- 举报
string::substr需要重新构造一个临时的string对象，这会引起效率损失。
不明白为啥要string aString=string(p);如果p是个零结尾的字符串数组，直接string aString=p；就可以了，何必再去构造一个临时对象string(p)再赋给aString。
不明白为啥要string aString=string(p);如果p是个零结尾的字符串数组，直接string aString=p；就可以了，何必再去构造一个临时对象string(p)再赋给aString。
taodm 2007-07-05
- 打赏
- 举报
总之，要实现string的那么多功能，string是最快的。
如果你只需要很少很少的功能，那么数组快。不过，“只需要很少很少的功能”也是很少很少很少发生的。
如果你只需要很少很少的功能，那么数组快。不过，“只需要很少很少的功能”也是很少很少很少发生的。
taodm 2007-07-05
- 打赏
- 举报
自己实际测一下就知道了。
string的主要优势是，如果你要填入第1025个字符的时候你该怎么办。
string的主要优势是，如果你要填入第1025个字符的时候你该怎么办。
loops 2007-07-05
- 打赏
- 举报
现在的std::string的确没有包含过多的技巧，但是简单的实现并不等于不好。
引用计数+Copy On Write机制，对于内容大致都不同的string，只会白白的增加维护那个机制的成本。
hashcode 排序的字符串比较，对于大量字符串间的比较有好处，对于两个简单的字符串的一次比较，比如“abc" "cad"，白白增加计算hash值的时间和浪费存储hash值的空间。
没有见到过一种string的方案，可称得上完美和普适任何情况。一切取决于解决问题的需要。
简而言之，exString和string都有存在的必要。
引用计数+Copy On Write机制，对于内容大致都不同的string，只会白白的增加维护那个机制的成本。
hashcode 排序的字符串比较，对于大量字符串间的比较有好处，对于两个简单的字符串的一次比较，比如“abc" "cad"，白白增加计算hash值的时间和浪费存储hash值的空间。
没有见到过一种string的方案，可称得上完美和普适任何情况。一切取决于解决问题的需要。
简而言之，exString和string都有存在的必要。
mLee79 2007-07-05
- 打赏
- 举报
如果基于 引用计数+COW 实现, 大多数的字符串赋值, substring , const string pooling 等等情况下都无需产生内存的分配与释放....
如果是使用字符串数组, 我还会为非使用字典顺序的字符串大小比较提供使用 hashcode 排序的字符串比较....
字符串的搜索至少应该提供可以选择的更加高效的实现, 而不是仅仅提供一个平凡的实现 ....
stl 确实不是以 thread safe 为目的, 但是如果这门基于实用主义的的语言能够稍微牺牲下所谓的优雅性, 以原子的方式处理引用计数(虽然这不是语言本身的功能), 很容易的就可以弄出一个thread safe的基于引用计数的更加高效的 exString 出来 ...
从本质上说, 现在通行的 std::string 的实现基本是一个非常平凡的实现, 并未包含过多的技巧 ....
如果是使用字符串数组, 我还会为非使用字典顺序的字符串大小比较提供使用 hashcode 排序的字符串比较....
字符串的搜索至少应该提供可以选择的更加高效的实现, 而不是仅仅提供一个平凡的实现 ....
stl 确实不是以 thread safe 为目的, 但是如果这门基于实用主义的的语言能够稍微牺牲下所谓的优雅性, 以原子的方式处理引用计数(虽然这不是语言本身的功能), 很容易的就可以弄出一个thread safe的基于引用计数的更加高效的 exString 出来 ...
从本质上说, 现在通行的 std::string 的实现基本是一个非常平凡的实现, 并未包含过多的技巧 ....
