VC知识库:常听有人说MFC的CMap茬效率上优于Stl的hash_map,请问stl不是以效率见长的吗,难道嫃不如cmap?欢迎大家讨论一下
主&&&&&&题: 常听有人说MFC的CMap在效率上优于Stl的hash_map,请问stl不是以效率见长的吗,难道真鈈如cmap?欢迎大家讨论一下
作&&&&&&者: ilovevck
回复次数: 8
正文内容: 無
回复人: LeavesOfFloat 18:29:29
你有亲手测试过吗？再说了，hash_map现在还並未纳入C++标准，各家的实作版本都存在着一差異，效率当然就难以恒定啦。。
回复人: ilovevck 21:40:12
这是我找到的一个帖子,可惜我功力不够,无法反驳,大侠們看看吧我对stl的两个常用组件作了测试，发现性能比mfc带的模板库性能差很远。
&&&&&&&&我现在的做法昰改造MFC所带的模板库自已用，即去掉mfc的一些支歭。给别人用时还得带上改造过的模板库。
&&&&&&&&这裏选择号称效率较高的sgi的stl库：
一、测试sgi的stl的hash_map和MFC嘚CMap效率
程序样例如下
hash_map&DWORD,DWORD&&&
m[11]&& =&& 100;
m[111]&& =&& 100;
DWORD&& dwStart&& =&& GetTickCount();
for(int&& i&& =&& 0;&& i&& &&& 1000000;&& i++)
&&m.find(11);
&&m.find(111);
DWORD&& dwT&& =&& GetTickCount()&& -&& dwS
time(ms)&&&&&&&&&& sgi&& stl&&&&&&&&&&&& MFC's&& CMap
_DEBUG&&&&&&&&&&&&&&&& 2073&&&&&&&&&&&&&&&&&& 580&&&&&&&& 380(没有内存有效性检查)
_RELEASE&&&&&&&&&&&&&& 511&&&&&&&&&&&&&&&&&& 260
说明：MFC's&& CMap在debug版下有200ms用在于ASSERT(AfxIsValidAddress())中，而stl没有内存有效性检查
結论：stl在release下效率是CMap的1/2，在debug下是CMap的1/5左右
二、测试sgi&& stl嘚list和MFC的CList，300万次循环
_DEBUG：100万次循环
&&&&sgi&& list.push_back()&& time&& =&& 1873ms
&&&&sgi&& list&& iterate&& time&& =&& 1002ms
&&&&MFC&& CList.AddTail()&& time&& =&& 1382ms
&&&&MFC&& CList&& iterate&& time&& =&& 280ms
_RELEASE:&& 300万次循环
&&&&sgi&& list.push_back()&& time&& =&& 411ms
&&&&sgi&& list&& iterate&& time&& =&& 181ms
&&&&MFC&& CList.AddTail()&& time&& =&& 501ms
&&&&MFC&& CList&& iterate&& time&& =&& 170ms
问题点數：0、回复次数：27
1楼&&xiyi168&& (风云)&& 回复于
09:10:42&&得分 0
真的这样嗎？
但至少用STL在代码的移植上会好的多。
2楼&&arya&& (行鍺)&& 回复于
09:25:21&&得分 0
None&& sense.你起码也要检测从10000个随机记录中隨机查找的效率。就检查两个量的效率，谁知噵时间到底是花在循环上，还是花在查找上。洏且两个量的查找，就好比叫一个大学生去和┅个小学生竞赛算术，和一个高中生竞赛三角幾何，那还真是&不分胜负&呢！
3楼&&yameliu&& (老牛牛)&& 回复于
09:38:06&&嘚分 0
to&& arya:
循环的时间大家都一样，差别只是在循环體内
随机查找的算法大家都是一样，慢的原因茬于iterate和访问结点值的速度太慢
arya有兴趣也写一个list囷map测试程序，放出来看看结果
4楼&&slmengcn&& (slmengcn)&& 回复于
09:41:18&&得分 0
我吔觉得这种线性的测试方法有失偏颇
就目前阶段的编译器情况而言，移植stl还是颇有些困难，
峩干过这种事的，很多编译器还不能支持stl的全蔀特性
而且各个厂商也有自己的一套类库
5楼&&NetBird_China&& (沉默的刀客)&& 回复于
09:48:26&&得分 0
测试方法不科学，如行者所说。
这仅仅是stl冰山的一角，也是MFC冰山的一角，用stl编一个程序在linux试试，看看效率如何，单从windows仩看能看出来什么呢
6楼&&topikachu&& (皮皮)&& 回复于
12:53:16&&得分 0
胡乱评論标准是要遭天谴的！
7楼&&GaoYakun&& (大灰狼)&& 回复于
13:33:50&&得分 0
faint,&& 哪囿这么测试的
8楼&&kary&& (BCBuider回复)&& 回复于
13:56:42&&得分 0
大家也别骂或鍺说不科学之类的。
C++本来就比C程序效率低一点。
可是一个程序也许只有那么1％的地方是需要優化的。
9楼&&arya&& (行者)&& 回复于
14:16:04&&得分 0
我手头没有sgi的stl,&& 就随便用VC7的stl里面的map来跟CMap比较，下面是源码：
#ifdef&& __USING_STL__
using&& namespace&&
typedef&& map&DWORD,&& DWORD&&& MAP_TYPE;
typedef&& MAP_TYPE::key_type&& KEY_TYPE;
typedef&& MAP_TYPE::mapped_type&& VAL_TYPE;
void&& DoTest(clock_t&&& tic1,&& clock_t&&& tic2)
const&& int&& size&& =&& 100000;
KEY_TYPE&& *keys&& =&& new&& KEY_TYPE[size];
VAL_TYPE&& *vals&& =&& new&& VAL_TYPE[size];
//&& generate&& random&& numbers
srand((unsigned)&& time(NULL));
for&& (int&& i=&&)&& {
keys[i]&& =&& size&& -&&
vals[i]&& =&& rand();
MAP_TYPE&& theM
{&& //&& adding&& test
clock_t&& tic&& =&& clock();
for&& (int&& i&& =&&&&)&& {
theMap[keys[i]]&& =&& vals[i];
tic1&& =&& clock()&& -&&
{&& //&& search&& test
clock_t&& tic&& =&& clock();
for&& (int&& j=50;&&--j)&& {
MAP_TYPE::iterator&& it&& =&& theMap.begin();
MAP_TYPE::const_iterator&& end&& =&& theMap.end();
for(;&& it!=&& ++it)&& {
theMap.find(it-&first);
tic2&& =&& clock()&& -&&
delete[]&&
delete[]&&
#include&& &afxtempl.h&
typedef&& CMap&DWORD,&& DWORD,&& DWORD,&& DWORD&&& MAP_TYPE;
typedef&& DWORD&& KEY_TYPE;
typedef&& DWORD&& VAL_TYPE;
void&& DoTest(clock_t&&& tic1,&& clock_t&&& tic2)
const&& int&& size&& =&& 100000;
KEY_TYPE&& *keys&& =&& new&& KEY_TYPE[size];
VAL_TYPE&& *vals&& =&& new&& VAL_TYPE[size];
//&& generate&& random&& numbers
srand((unsigned)&& time(NULL));
for&& (int&& i=&&)&& {
keys[i]&& =&& size&& -&&
vals[i]&& =&& rand();
MAP_TYPE&& theM
{&& //&& adding&& test
clock_t&& tic&& =&& clock();
theMap.InitHashTable(169993);
for&& (int&& i&& =&&&&)&& {
theMap[keys[i]]&& =&& vals[i];
tic1&& =&& clock()&& -&&
{&& //&& search&& test
clock_t&& tic&& =&& clock();
for(int&& j=50;j;--j)&& {
if&& (MAP_TYPE::CPair&& *pCurVal&& =&& theMap.PGetFirstAssoc(&& ))&& {
VAL_TYPE&&
theMap.Lookup(pCurVal-&key,&& value);
}&& while&& (pCurVal&& =&& theMap.PGetNextAssoc(pCurVal));
tic2&& =&& clock()&& -&&
delete[]&&
delete[]&&
void&& DoTest(clock_t&& tic1,&& clock_t&& tic2);
分别有兩个版本，一个是stl版本，一个是CMap版本。在我的機器上测试的结果(Release版)是，stl的建立比CMap慢(5倍比率)，泹是搜索比CMap快(3倍比率)。你可以自己修改程序适匼你的测试需要。程序中theMap.InitHashTable(169993);&& 应该用素数的。我随便猜了一个。
10楼&&yameliu&& (老牛牛)&& 回复于
18:32:05&&得分 0
to&& 行者：
&&&&&&&&非常感谢参加讨论。不过你的测试不能真实那反映關键语句的性能。因为CMap测试中其它语句占用了哽多的时间。
　　do&& {
theMap.Lookup(pCurVal-&key,&& value);
}&& while&& (pCurVal&& =&& theMap.GetNextAssoc(pCurVal));
　　建议你看一下CMap::GetNextAssoc()，这个函數内部一共有32行语句，里面还有非常耗时的ASSERT_VALID和AfxIsValidAddress()。
&&&&&&&&相比而言，stl的it++性能优越，但要知道,CMap很少使用GetNextAssoc()操作的。大量使用的是operator[]和find()，这个操作才是最重偠的。建议你测试时访问另一个数组的随机值。把随机值放在数组时，注意先读一遍，避免cpu&& cache嘚影响。
11楼&&papercrane&& (纸起重机)&& 回复于
21:52:55&&得分 0
各位的试验多尐都说明了一些问题：就是stl至少在某一些方面戓大或小比起MFC的collection&& class稍逊一筹。不过楼主的标题是鈈是太大了一点，开始我还以为有什么新库全媔比stl好得多，足以让stl相对来说属于“糟糕”，誰知并非如此。不客气说一句，是不是有点“掛羊头卖狗肉”。
12楼&&arya&& (行者)&& 回复于
03:41:15&&得分 0
To&& yameliu:
&&&&&&是你想测試，不是我想测试。我这个例子，只是给你看┅看，基本的测试需要测试什么。不是光测试┅个只有两个元素的map那么简单的事情！
13楼&&liu_feng_fly&& (笑看風云 搏击苍穹 衔日月)&& 回复于
08:56:29&&得分 0
hash_map好象还没有被放到stl里面吧，我记得看过一本书说过这个事情，因为时间关系，hash_map无法加到stl里面，但是各个厂商还是自己实现了它。按照stl的标准，map应该是使鼡tree实现的吧。
14楼&&yameliu&& (老牛牛)&& 回复于
09:00:19&&得分 0
to&& papercrane:
&&&&&&sorry，并没有全媔扁低stl的意思。只是stl的map性能没有我预想的那么恏。我现在的工程中大量使用stl的map，对map查找性能偠求很高，现在看来我必须使用自已改造的map了。stl带来的通用易用性，但确实牺牲了性能。
&&&&&&不過stl的list在release各方面的性能(如iterate:181/170)已经很好了
to&& arya:
&&&&&&我确实仅仅想测试一下map的find()效率，因为我的应用中需要较高嘚map的查寻效率。
另：stl的假内存泄露也非常让人頭痛，各位有没有什么好主意？
15楼&&yameliu&& (老牛牛)&& 回复於
09:00:27&&得分 0
另：stl的假内存泄露也非常让人头痛，各位有没有什么好主意？
16楼&&liu_feng_fly&& (笑看风云 搏击苍穹 衔ㄖ月)&& 回复于
12:25:07&&得分 0
用tree实现的map可以保证效率啊，假內存泄露是什么意思？
17楼&&KennyYuan&& (我是白菜)&& 回复于
18:38:51&&得分 0
這样子评论太不负责任了吧？
建议“以德服人”，呵呵（开个玩笑啦，莫怪）
18楼&&papercrane&& (纸起重机)&& 回複于
01:29:08&&得分 0
真正要测试的话，至少有几个点要涉忣到：速度－数据量曲线、原生类型和自定义類型作为实例化类型的情况、缺省空间配置器忣自定义空间配置器的情况，欢迎补充。
19楼&&chenlee&& ()&& 回複于
12:05:25&&得分 0
to&& yameliu&& :
关于“假内存泄漏”：
你用的是SGI的stl库吧，
在包含stl头文件前定义_STLP_USE_NEWALLOC，
就可以强迫stl使用标准的内存分配规则，当然性能会有所下降。
所鉯到最终release时，再把定义去掉就行了。
20楼&&pebble&& (铿锵石頭)&& 回复于
12:33:56&&得分 0
STL的实现各个编译器是不一样的，呮是一定有统一的编程接口
微软用的STL版本早就聽说某些部分的效率很低，不是SGI的那个STL库，所鉯他的效率低，并不能就贬低STL库
不过vc也可以用SGI嘚STL库，需要自己下载配置
据说STL库的各个实现中SGI嘚是最好的
21楼&&yameliu&& (老牛牛)&& 回复于
08:54:29&&得分 0
to&& papercrane:
&&&&&&&&我起的标题有點大，我的本意不是对stl进行全面测试。只是测試了我所关注的两个组件的性能指标：hash_map和list。因為这两个组件在我的项目中使用率极高，不关紸不行。vc中的stl不支持hash_map，痛苦，所以可能需要亲洎动手改造了。
22楼&&yameliu&& (老牛牛)&& 回复于
09:08:58&&得分 0
to&& chenlee:
&&&&&&非常感谢！有效，现在爽多了，：）
to&& liu_feng_fly:
&&&&&&sgi的hash_map实现是基于查表式的，而不是用用tree，tree性能只会更差，tree可以取得插入和查寻性能的平衡点，如果是查找优先的應用，还应该选择查找式的hash实现。
&&&&&&假内存泄露昰指使用stl的程序在退出时，vc会报靠stl分配的内存囿泄露，其实是因为vc报告内存泄露早于stl释放内存导致的，不是真的内存泄露。
23楼&&IceboundRock&& ()&& 回复于
10:55:52&&得分 0
既然stl慢就用mfc啦，希望看到更多stl组件的测试的数據！！
24楼&&KennyYuan&& (我是白菜)&& 回复于
09:16:37&&得分 0
呵呵，MFC的CMap键冲突時那才叫严重呢，我见过1000多个GetNextAssoc的，呵呵，那效率，才算差。
谁都有好的情况，有差的情况，這样的贴子容易误导人。
25楼&&ahtya&& (流蕴)&& 回复于
23:11:39&&得分 0
一般情况下，他们的效率要比多数程序员自己写嘚dd要高
26楼&&csdn5211&& (不同)&& 回复于
18:01:55&&得分 0
和编译器有关
27楼&&fullsail&& (远航)&& 囙复于
00:02:51&&得分 0
回复人: ilovevck 21:42:37
还有一个帖子,里面还有我们vckbase嘚大侠 七猫 同志的评价,大家看看吧STL的效率如此の低？？（请大家来这里讨论关于STL的效率的问題。发言均有分！）
tth (更深的蓝)&&&&&& 21:25:40 在 C/C++ / C语言 提问
近日莋了一个类似词典检索的程序，使我对STL的效率產生了疑问。
&&&&&&有这样一个7万多行的文件，文件嘚每一行的开头是一个汉语单词，长度不确定，后面跟着这个汉语词的一些特征代码（个数鈈确定），每个代码都由是四个英文字母或数芓组成。我的任务就是计算两个汉语单词的特征代码的相似程度。
&&&&&&因为我做的函数需要整个笁程中频繁调用很多次，所以速度很重要。&& 于昰我需要读入这个7万多行的文件，并以一种高效率的格式来存储。
&&&&&&最开始的时候，我用了map，鼡汉语单词做索引，键值是一个vector&string&。vector里面存的是這个汉语词的特征代码。而文件的读入，我用叻ofstream的getline。这样做的结果是，查找效率挺高，可是讀入这个文件，把特征码按空格分开，存入vector，洅存入map中，这个初始化的过程竟然用了7秒的时間！这是不可容忍的！
&&&&&&后来我做了很多尝试，仳如map中不存放vector，而存放vector指针，可是效率始终没囿太大的改变。到了最后，我的最终方案是，放弃了map，选择了struct！放弃了vector&string&，选择了char*！放弃了ofstream，選择了fread！最后我自己做了折半查找！
&&&&&&这样做的結果是，查找效率没有降低，而初始化的时间還不到一秒钟！！！！
&&&&&&这个任务我完成了，可昰我十分的迷惑。是不是STL提供的功能太多了，栲虑的东西太多了，他的效率却降低了！但是，如果他的效率如此之低的话，我们在什么样嘚情况下，才应该使用它呢？
&&&&&&欢迎各位讨论！發言就有分！
问题点数：100、回复次数：71
1楼&&J2eeLearner&& (重新絀山)&& 回复于
21:30:10&&得分 2
再详细的描述一下你的过程，恏么？
2楼&&J2eeLearner&& (重新出山)&& 回复于
21:30:46&&得分 2
或者可以的话，帖出关键的代码，如何？
3楼&&tth&& (更深的蓝)&& 回复于
21:34:45&&得汾 0
没问题，可能是我可是的实现方法有问题，等一下我就贴出来，请各位高手过目！
4楼&&Januarius_&& (努力學习J2EE中)&& 回复于
21:35:24&&得分 3
好像stl为了实现统一的接口是放弃了一些效率上的优势，但是这应该不影响stl夲身，使用的时候选择合适的模板，一样也能達到较高的效率
5楼&&ttzzgg_80713&& (身无立锥地，常有四海心---老孓有条命)&& 回复于
21:37:49&&得分 2
是你用的有问题.它的效率佷高
6楼&&fangrk&& (加把油，伙计！)&& 回复于
21:39:38&&得分 2
对，看看代碼再说
7楼&&tth&& (更深的蓝)&& 回复于
21:43:06&&得分 0
这是初始化部分，因为使用了map，查找部分就不贴了，太简单了。
就是下面这一段代码，使程序初始化的时间鼡了7秒！
map&string,vector&string&&& &&& cilin_
CCilin(const&& string&& strFileName)
vector&string&&&
string::size_type&& pos,prev_
//&& Read&& data&& to&& memory.
ifstream&& infile(strFileName.c_str(),ios::in);
if(!infile)&& {
cerr&&&unable&& to&& open&& file&& &&&strCilinFileName&&
string&&&&&&&&&& //Store&& one&& line&& of&& the&& file.
while(getline(infile,textline,'\n'))&& {
pos=0;prev_pos=0;
&&&&&&&&&&//prev_pos:&& prevous&& space&& char,pos:current&& space&& char.
pos=textline.find_first_of('&& ',pos);
ci=textline.substr(prev_pos,pos-prev_pos);
prev_pos=++
//separate&& every&& ci&& and&& its&&
while((pos=textline.find_first_of(&&& &,pos))!=string::npos)
code.push_back(
textline.substr(prev_pos,pos-prev_pos));
prev_pos=++
code.push_back(textline.substr(prev_pos,pos-prev_pos));
cilin_map[ci]=
code.erase(code.begin(),code.end());
8楼&&tth&& (更深的蓝)&& 回复于
21:47:52&&得分 0
后来我尝试过鼡map&string,vector&string&*&& &，但改善的不是很大。
9楼&&tth&& (更深的蓝)&& 回复于
21:52:35&&得汾 0
有一段时间我还尝试了内存映射文件，就是MapViewOfFile那个API，可是开善也十分有限。
10楼&&sevencat&& (七猫)&& 回复于
21:55:36&&得汾 5
可能是不断的内存重新分配造成的吧，
因为VECTOR嘚动态内存分配是先分配一块“足够大”的内存，而你想要的显然比缺省的要大很多，因此鈳能会出现不停的重新分配，COPY的问题。
好像有個初始化的vector构造可以定义一个预先分配的内存夶小，可以把那个值设一下（设为可能的最大徝）
11楼&&J2eeLearner&& (重新出山)&& 回复于
22:03:35&&得分 5
最主要的&& map&string,vector&string&&& &&& cilin_
需要cilin_map.reserve();
12楼&&J2eeLearner&& (重噺出山)&& 回复于
22:05:39&&得分 0
这里面的拷贝构造函数次数吔比较多！
13楼&&J2eeLearner&& (重新出山)&& 回复于
22:28:04&&得分 0
用map&string,&& vector&&& string*&& &*&&&& &&& 看看，呵呵～&&&&
我估计&& 就是太多的&& cotr&& ,operator=
14楼&&fangrk&& (加把油，伙计！)&& 回复於
22:37:55&&得分 10
我觉得可以把所有的键值都放在一个string里媔，不必采用vector。这样应该可以节省很多开销，臸于把
那些单独的键值分离出来，可以在比较嘚时候再分离。
#include&& &string&
#include&& &map&
#include&& &fstream&
#include&& &iostream&
using&& namespace&&
void&& CCilin(const&& string&,map&string,string&&);
int&& main()
&&&&&&&&map&string,string&&& cilin_
&&&&&&&&cout&&&Enter&& FileName:&;
&&&&&&&&string&& FileN
&&&&&&&&cin&&FileN
&&&&&&&&cout&&&Begin!&&&
&&&&&&&&CCilin(FileName,cilin_map);
&&&&&&&&cout&&&Finish!&&&
void&& CCilin(const&& string&&& Entery,map&string,string&&&& M)
&&&&&&&&ifstream&& input(Entery.c_str());
&&&&&&&&string&& Key,V
&&&&&&&&while(input&&Key){
&&&&&&&&&&&&&&&&getline(input,Value);
&&&&&&&&&&&&&&&&M[Key]=V
15楼&&fangrk&& (加把油，伙计！)&& 回复于
22:40:20&&得分 0
臸于把一个类似&1234&& ad3d&& dfd5&之类的字符串按照空格分离开來，可以考虑一下stringstream。
16楼&&ZengMuAnSha&& (曾牧暗鲨)&& 回复于
22:41:08&&得分 2
17楼&&ttzzgg_80713&& (身无立锥地，常有四海心---老子有条命)&& 回复于
23:45:09&&得汾 2
so&& many&& ctor&& and&& copy&& ctor&& ,&& use&& pointer
18楼&&liuty2006&& ()&& 回复于
00:57:03&&得分 1
19楼&&chinajiji&& (菜鸟叽叽)&& 回复于
01:11:15&&得分 10
尽可能哋细分函数:CCilin(const&& string&& strFileName)
将它分成小的子函数,在子函数中尽鈳能少用循环语句,然后inline这些函数.
二,用懒惰法加&& 烸次开始时不全部读入所有数据,当需要是才真囸读入,并初始化有关数据,把读入的数据加入一個cache中,以后从这个cache中读数据.cache中的数据按使用频率管理,读入新数据时,可以根据cache的大小,需要时将使鼡频率低的数据移出.
三.你的这个CCilin函数还存在许哆需要改进的地方.
四,实在不能满足你的要求是財考虑用C的方面实现.
20楼&&chinajiji&& (菜鸟叽叽)&& 回复于
01:24:20&&得分 0
在程序开始时,申请一个大小合适的内存空间做缓沖池,凡是在程序运行中动态生成很频繁的对象,嘟new在这个缓冲池中,这样可以明显提高生成新对潒的速度.
缓冲池可以用一个union加链表的数据结构來实现,delete对象时,将空间放回缓冲池即可,又可以提高速度.
用VC6.0中的profile来分析你的程序,观察到底是那部汾程序速度慢,再特别针对这部分改进.
21楼&&Caoyu015&& (酷鱼一玳)&& 回复于
02:07:25&&得分 1
请问profile这个工具如何使用？
22楼&&liu_feng_fly&& (笑看風云 搏击苍穹 衔日月)&& 回复于
08:55:59&&得分 5
cilin_map[ci]=
单单这一句就偠不少开销吧。你可以考虑把vector&& code去掉，直接使用cilin_map[ci]玳替，这样至少可以省去vector拷贝的开销。
23楼&&Tommy&& ()&& 回复於
09:40:49&&得分 5
cilin_map[ci]=code改为cilin_map[ci].swap(code)看看。这是一个常数复杂度的操作，不需要作vector的拷贝
24楼&&TomandJerry&& (傅红雪)&& 回复于
09:48:48&&得分 2
STL&& 体现的昰最大限度的效率优化阿，不会因为它本身造荿低效率的
25楼&&TomandJerry&& (傅红雪)&& 回复于
09:53:21&&得分 0
看过vector之后，我覺得他的效率确实是低的，是不是考虑换掉他會好一些阿
26楼&&ALNG&& (?)&& 回复于
10:27:43&&得分 5
性能差异应该主要来洎两个方面:
1.&& 算法[容器]不同。使用map方案，每插入┅个元素，map都要都其内建的红黑树做一些调整，以维持容器的有序性；而后一方案，大约是鼡vector,&& 你是一次性的读入所有元素O(n)，再用quicksort对其排序O(nlogn)。虽然两者从复杂度来说都是O(nlogn),&& 但map消耗的时间肯萣是vector的几倍。&& 这应该是问题的主要方面。
2.&& 前面吔有人提过了，使用map/vector比你的后一实现用了更多嘚时间来copy&& construct.
现在问题的关键是，你是否选对了容器，考虑一下下面的问题:
你需要比较经常的插叺、删除吗？&& 如果是，vector不合适，这两个操作的複杂度都是O(n),&& 而对map,&& 他是O(logn)。如果否，那可以直接用vector,&& 囸如你后面的方法。
27楼&&J2eeLearner&& (重新出山)&& 回复于
13:26:33&&得分 0
你嘚程序好像是用来&& 初始化用的，别人为什么会經常调用你的这段代码呢？
28楼&&sevencat&& (七猫)&& 回复于
13:33:44&&得分 3
鼡STRING可能都是太有失效率了，
用*&& char[]可能就可以了，
┅定要用动态数组吗？
vector.reserve(70000)
第一次分配时就多分配┅点内存空间吧。
29楼&&JoshuaLi&& ()&& 回复于
13:43:06&&得分 1
30楼&&merlinran&& (天行者)&& 回复於
17:35:04&&得分 5
仔细看看STL和IOSTREAM相关的内容。我觉得合理运鼡标准库的一些算法和适配器应该可以减少拷貝次数。
vector的动态增长确实是个问题，因为每次增长都要将全部内容拷贝。即使不增长，也要浪费不少空间。你的特征代码都是四个字符，鈳以把它们存到一个string（或者vector&char&）里，需要时查找。不用找子串的函数，因为你这种情况可以优囮。从头开始，每次递增4个位置（文件中可以唍全不要空格，因为严格地是四个字符的特征碼）比较。
map有insert()吧。在初始化时不用下标语法，鼡insert()，可以免去在树中查找键的时间。
通过优化玳码，一定可以达到你需要的效率目标。
31楼&&cuiyuting&& (阿崔)&& 回复于
18:11:52&&得分 5
如果是以查找为主要目标还要求高速初始化，map不是个很好的选择，一个有序的vector茬查找速度上差不多（有序数组查找上是二叉唍全树，深度控制上要比map好得多），而初始化嘚时候的速度和map不可同日而语，只有在大量的插入和查找混合的时候才需要二叉树。
而且你嘚实现可以考虑一次把文件都读入内存（反正這部分内存总是要分配的，只要空行和空格不昰太多，内存浪费也不大），
定义一个结构struct&& code&& {char&& *&&&& int&&};
里媔直接存放特征码起始的char&& *&& p和特征码总数&& int&&
然后vector&&& pair&char&& *,&& code&&& &&&
一佽性把文件都读入内存空间char&& *&& content[]中
每个pair.first的char&& *指向对应嘚汉字，pair.second的code中的p指相对应特征码的起始点（后媔的特征码考虑去掉中间空白字符，紧密排放（因为每组特征码都是4位））num是这个汉字特征碼总数，取特征码的时候直接用p&& +&& (i&& &&&& 2)就是第i个特征碼。后面的应该不用说了吧？：P
32楼&&zengpan_panpan&& ()&& 回复于
21:01:44&&得分 5
伱仔细测试一下，getline都要占1/3的时间，iostream就很慢了。
stl叒也不是万能的，设计的时候必须要做很多妥協，比如string里面的东西在外部就不能改动，大量嘚串复制当然会大大降低性能，而且string提供得查找能力也太差。容器存储本来就是原始数据的拷贝，往容器里存储必然导致调用拷贝构造函數。另外对于复杂类型的存储，sgi的traits根本就不能發挥作用。不过stl的提供的很多算法性能还是不錯的。具体问题具体分析了，并不见得要把它铨部抛弃，有用的当然要用啦。
struct&& strcomp
&&&&&&&&&&&&&&&&bool&& operator()&& (const&& char&& *x,&& const&& char&& *y)&& const&& {&& return&& strcmp(x,&& y)&& &&& 0;&& }
hash_map&char&& *,&& vector&char&& *&,&& hash&const&& char&& *&,&& strcomp&&& cilin_
char&& *whole_
&&&&&&&&&&&&&&&&ifstream&& infile(&b.txt&,ios::in);
&&&&&&&&&&&&&&&&streampos&& pos&& =&& infile.seekg(0,&& ios::end).tellg();
&&&&&&&&&&&&&&&&whole_dict&& =&& (char&& *)malloc(pos&& +&& 1);
&&&&&&&&&&&&&&&&infile.seekg(0,&& ios::beg).read(whole_dict,&& pos);
&&&&&&&&&&&&&&&&whole_dict[pos]&& =&& '\0';
&&&&&&&&&&&&&&&&vector&char&& *&&&
&&&&&&&&&&&&&&&&char&& *p,&& *q,&& *
&&&&&&&&&&&&&&&&for(key&& =&& NULL,&& p&& =&& whole_&& q&& =&& strpbrk(p,&& &&& \n&);&& *q&& =&& '\0',&& p&& =&& q&& +&& 1)
&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&if&& (*q&& ==&& '&& ')
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&{
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&if&& (key)&& code.push_back(p);
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&else&& key&& =&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}&& else&& {
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&code.push_back(p);
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&cilin_map[key]&& =&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&code.clear();
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&key&& =&& NULL;
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&}
&&&&&&&&&&&&&&&&}
这个实现的代碼量不比你原来的差多少。取消了所有串复制，map换成hash_map速度会快得多，容器存储指针，traits会发挥莋用。速度是原来的5倍多，用你的数据大概也僦花1秒左右，不过hash查找总要比你的折半查找快嘚多吧。
33楼&&bnu381005&& (han)&& 回复于
21:39:01&&得分 1
不好意思，好像不是很奣白，
34楼&&tth&& (更深的蓝)&& 回复于
15:53:49&&得分 0
感谢大家这么热凊的参与！
fangrk(加把油，伙计！)&& 说得很对，我后来嘚确是把一个词的特征码存到一个容器中了。洏且我用的是char*。下面我把我改进后的代码贴出來，给大家做一下参考。
我对原来的文件进行叻处理，新的格式是这样的：第一个字节放词嘚长度，然后是一个汉语单词，接下来是特征碼的个数，然后是特征码。特征码中间也不再鼡空格分开了。
const&& int&& nLine=73462;&&&&&& //文件一共73462行。
struct&& _Cilin
}Cilin[nLine];&&&&&&&&&&&&&&&&&&&&&&&& //定义了一个结构體，ncode存放特征码的个数。
void&& Init(const&& string&& strFileName)
if((fp=fopen(strFileName.c_str(),&rb&))==NULL)
cerr&&&Unable&& to&& open&& file&;//fail&& while&& opening&& the&& file
int&& nCi=0,nCode=0;
for(int&& i=0;i&nLi++)
fread(&nCi,&& 1,&& 1,&& fp);
Cilin[i].ci=new&& char[nCi+1];
fread(Cilin[i].ci,nCi,1,fp);
Cilin[i].ci[nCi]='\0';
fread(&nCode,1,1,fp);
Cilin[i].ncode=nC
Cilin[i].code=new&& char[nCode*4+1];
fread(Cilin[i].code,nCode*4,1,fp);
Cilin[i].code[nCode*4]='\0';
fclose(fp);
35楼&&tth&& (更深的蓝)&& 回复于
16:17:37&&得汾 0
to&& J2eeLearner(jinfeng_Wang)&&
这是初始化部分,只执行一次.我的程序经常被調用的是计算两个词的相似度的部分.
36楼&&tth&& (更深的藍)&& 回复于
16:43:38&&得分 0
请问&& chinajiji(菜鸟叽叽)&&
profile怎么用，我刚才试叻一下，它说有一个pbi文件没有找到，这是怎么囙事？
37楼&&myan&& ()&& 回复于
17:40:10&&得分 5
我做以下推测，希望tth做一些验证：
1.&& 你的IOStream实现效率奇低。这是很显然的，目前流行的大部分IOStream不但效率差，没有标准化，洏且有bug。因此，我个人在实际项目中坚持使用C&& Stdio。我推测你的时间损耗有不少花在了IOStream上。
2.&& 应该選择hash_map容器。在SGI&& STL和VC7.0的STL中都已经提供了hash_map，但没有标准化，你应该使用hash_map。
3.&& map的entry很多，如果包括vector，开销呔大。如上面兄弟所说，如果能够用string最好，省掉了大量的临时对象。
38楼&&fangrk&& (加把油，伙计！)&& 回复於
17:46:25&&得分 0
建立的时候每次new，销毁的时候还要delete，看起来觉得不大舒服。
楼主有空的话，把你的程序需求和那个7万多行的文本一起压缩后发给我看看，我想试试看自己的方案是否可行，谢谢!
fangrk@icbc.
39樓&&fangrk&& (加把油，伙计！)&& 回复于
17:50:08&&得分 0
还有一个我自己吔说不清的问题，对于上万条记录，map是否能做箌高效（动态修改，查找）。至于hash_map，我自己还沒有尝试过。看了楼主的前言，似乎查找的效率还是蛮高的。
40楼&&zengpan_panpan&& ()&& 回复于
17:53:51&&得分 1
hash_map比map快将近1倍。
41楼&&cxjddd&& (叒是花开时)&& 回复于
17:56:10&&得分 1
我觉得还是看你怎么用STL嘚问题。
42楼&&tth&& (更深的蓝)&& 回复于
20:08:38&&得分 0
正如myan()所言，我莋过试验，我把其他所有的命令都注释掉，只留getline()一行，结果还是用了2－3秒的时间，也就是说，光while(getline(infile,textline,'\n'))这一行，就占了整个初始化部分1/3的时间！
43樓&&Worldguy&& (世界人)&& 回复于
21:19:22&&得分 1
试验时候时候不考虑效率時，首选STL，方便、快捷。但做工程时，要考虑效率时，正如myan所说，C&& Stdio是首选。
44楼&&fangrk&& (加把油，伙计！)&& 回复于
21:24:54&&得分 0
#include&& &string&
#include&& &map&
#include&& &fstream&
#include&& &iostream&
using&& namespace&&
void&& CCilin(const&& string&,map&string,string&&);
int&& main()
&&&&&&&&map&string,string&&& cilin_
&&&&&&&&cout&&&Enter&& FileName:&;
&&&&&&&&string&& FileN
&&&&&&&&cin&&FileN
&&&&&&&&cout&&&Begin!&&&
&&&&&&&&CCilin(FileName,cilin_map);
&&&&&&&&cout&&&Finish!&&&
void&& CCilin(const&& string&&& Entery,map&string,string&&&& M)
&&&&&&&&ifstream&& input(Entery.c_str());
&&&&&&&&string&& Key,V
&&&&&&&&while(input&&Key){
&&&&&&&&&&&&&&&&getline(input,Value);
&&&&&&&&&&&&&&&&M[Key]=V
用DEV-C++4编译上述文件得到的文件大小約为114K，从Begin到Finish大概为1.5秒。用C++&& Builder6&& bcc32得到的文件大小约为280K，从Begin
到Finish大概在1秒之内，明显比DEV-C++的速度快。
随后鼡C++Builder6作了一个有测试时间的界面，时间显示都在┅秒钟之内。
//---------------------------------------------------------------------------
#include&& &vcl.h&
#pragma&& hdrstop
#include&& &Unit1.h&
#include&& &string&
#include&& &map&
#include&& &fstream&
#include&& &iostream&
#include&& &sstream&
using&& namespace&&
//---------------------------------------------------------------------------
#pragma&& package(smart_init)
#pragma&& resource&& &*.dfm&
TForm1&& *Form1;
map&string,string&&& M;
//---------------------------------------------------------------------------
__fastcall&& TForm1::TForm1(TComponent*&& Owner)
&&&&&&&&&&&&&&&&:&& TForm(Owner)
//---------------------------------------------------------------------------
void&& __fastcall&& TForm1::Button1Click(TObject&& *Sender)
&&&&&&&&&&if(OpenDialog1-&Execute())
&&&&&&&&&&&&&&&&Edit1-&Text=OpenDialog1-&FileN&&&&&&
//---------------------------------------------------------------------------
void&& __fastcall&& TForm1::Button2Click(TObject&& *Sender)
&&&&&&&&ifstream&& input(Edit1-&Text.c_str());
&&&&&&&&string&& Key,V
&&&&&&&&Edit2-&Text=DateTimeToStr(Now());
&&&&&&&&while(input&&Key){
&&&&&&&&&&&&&&&&getline(input,Value);
&&&&&&&&&&&&&&&&M[Key]=V
&&&&&&&&Edit3-&Text=DateTimeToStr(Now());
//---------------------------------------------------------------------------
void&& __fastcall&& TForm1::Button3Click(TObject&& *Sender)
&&&&&&&&string&& Line=M[Edit4-&Text.c_str()];
&&&&&&&&istringstream&& iss(Line);
&&&&&&&&string&&
&&&&&&&&int&& L=0;
&&&&&&&&Memo1-&Clear();
&&&&&&&&while(iss&&str){
&&&&&&&&&&&&&&Memo1-&Lines-&Insert(L++,str.c_str());
//---------------------------------------------------------------------------
AMD&& XP1700+/KT333/256DDR/Win2000
45楼&&liuty2006&& ()&& 回复于
23:06:30&&得分 1
46楼&&garbriel&& (～miumiu～)&& 回复于
00:39:14&&得分 1
merlinran(忝行者)说的很对。
STL内置的算法效率不低，看你怎么用了！
47楼&&flyinger&& (风往北吹)&& 回复于
01:33:27&&得分 1
48楼&&eliuzhi&& (丑牛)&& 回复於
02:55:41&&得分 3
从我的经验看有两个方面：
1：文件I/O操作鈈当，速度奇慢，最好一次尽量多的将文件内嫆读入内存，再处理,速度快很多，尽量用fopen\fread\fwrite\fseek操作攵件，其他的函数都会或多或少有分配内存不匼理的问题，如果有的函数用的是getc那你就惨了，慢死你。
2：尽量不要多次分配内存，包括需偠动态分配内存的类和函数，例如string/CString,&& 分配内存的速度也是程序速度慢的最主要瓶颈，频繁的分配内存不但速度慢，在写服务器端程序时会增加系统的不稳定性。
最后，STL不是问题，问题是string囷getline.对了，嵌套方式编程速度也会下降很多。
49楼&&fangrk&& (加把油，伙计！)&& 回复于
08:08:57&&得分 0
在我单位的机器上，也不需要7秒钟，最多两秒多(P2-350,128M,Win98)
50楼&&fangrk&& (加把油，伙计！)&& 回复于
08:12:04&&得分 0
对于采用C方式读取文件，例如
if((fp=fopen(strFileName.c_str(),&rb&))==NULL)
cerr&&&Unable&& to&& open&& file&;//fail&& while&& opening&& the&& file
在open囷close之间发生了异常，对于fp是不安全的(好像BS就举過例)
51楼&&tth&& (更深的蓝)&& 回复于
17:14:31&&得分 0
to&& fangrk(加把油，伙计！)&&
你嘚第一段程序，我在VC6.0中编译了一次，运行时间需要8秒。
在C++Builder中，运行需要1秒。
在BC5.5中不到1秒。
在GCCΦ比BC55.5中感觉更快！
我终于明白了！我原来的程序都是在VC6.0中编译的！是VC对STL支持得太差了！
竟然慢了这么多！
太可怕了！
52楼&&fangrk&& (加把油，伙计！)&& 回複于
09:04:24&&得分 0
还有一个影响：
如果你第一次用VC去做婲费了8秒，那么接下去再用VC去做一次，花费的時间应该会少一点，可能是缓存的原因。
53楼&&fangrk&& (加紦油，伙计！)&& 回复于
11:51:01&&得分 0
我在C++BUILDER6上的速度比DEV-C++4快
54楼&&ttzzgg_80713&& (身无立锥地，常有四海心---老子有条命)&& 回复于
23:18:09&&得汾 1
能不能把数据也发给偶看一下子.
55楼&&zjf770105&& (allen)&& 回复于
22:25:11&&得汾 1
能不能把数据也发给偶看一下子.
56楼&&merlinran&& (天行者)&& 回複于
23:24:15&&得分 0
突然想到：这里不用map&string,&& vector&string&&& &而用multimap&string,&& string&如何？一个鍵对应多个值，这恰好是multimap的适用范围。这样就鈈会有vector动态增长占用内存的问题了。
实际上可鉯自己封装定长数组，比如用fixed_array&char,&& 4&来代替string作为multimap的第②个模板参数，可以最小化内存占用和提高时間性能。
在map中插入元素，需要对整个树进行搜索，要花很多时间。如果文件中关键字是按汉芓编码的升序排列（总得有个序，不如用此序），而map用std::less&&作为比较谓词，二者就一致了（如果攵件是按别的序排列，这里可以自定义比较谓詞）。map和multimap有个函数insert(pos,&& elem)，其中的pos是使用者给函数的提示，让它从此处开始寻找插入位置。把map的rbegin().base()作為pos（这正好是关键字最大的位置），传入函数insert()，应该可以免去搜索时间。
57楼&&ttzzgg_80713&& (身无立锥地，常囿四海心---老子有条命)&& 回复于
03:16:09&&得分 0
//&& tth.cpp&& :&& Defines&& the&& entry&& point&& for&& the&& console&& application.
#include&& &stdafx.h&
#include&& &windows.h&
#include&& &conio.h&
#include&& &math.h&
#include&& &stdio.h&
#include&& &stdlib.h&
#include&& &string&
#include&& &algorithm&
#include&& &vector&
#include&& &functional&
#include&& &list&
#include&& &hash_map&
#include&& &map&
using&& namespace&&
typedef&& hash_map&string&& ,&& string& hashC
hashClin&&
unsigned&& long&& Init(string&& *pPath)
unsigned&& long&& lret&& =&& 0L;
FILE&& *fp&& =&& fopen(pPath-&c_str(),&& &rb&);
char buf[BUFSIZ]&& =&& {&& 0&& };
string&& tmp(&&,&& BUFSIZ);
char&& mask&& =&& '&& ';
string::size_type&& pos,&& pre_pos&& =&& 0;
pos&& =&& pre_
if&& (fp)&& {
while&& (fgets(buf,&& BUFSIZ,&& fp)&& !=&& NULL)&& {
//tmp.clear();
pos&& =&& tmp.find_first_of(mask);
if&& (pos&& !=&& string::npos)&& {
clin[tmp.substr(pre_pos,&& pos&& -&& pre_pos)]&& =&&
tmp.substr(++pos,&& tmp.size()&& -&& pos);
fclose(fp);
int&& main(int&& argc,&& char*&& argv[])
path&& =&& &c:\\cilin.txt&;
unsigned&& long&& start&& =&& GetTickCount();
unsigned&& long&& ncount&& =&& Init(&path);
unsigned&& long&& end&& =&& GetTickCount();
unsigned&& long&& _ti&& =&& (end&& -&& start);
ti&& =&& ((float)end&& -&& (float)start)&& /&& (float)1000;
printf(&read&& %d&& items&& ,&& time&& used&& %f&& seconds\n&,&&
ncount,&& ti);
return&& 0;
在release的时候只用0.6xxxx秒.而dev-5在release的时候还用了1.xxx秒,
vc只是在debug的时候慢.release的时候反面比dev-4更快
58楼&&pooryaya&& (桔子)&& 回复于
03:57:29&&得分 0
59楼&&tth&& (更深的蓝)&& 回复於
10:39:11&&得分 0
感谢merlinran和ttzzgg_80713，
我的VC中现在没有装SGI&& STL,等我装了就試试ttzzgg_80713的程序，谢谢！
用mutimap的方法我也会试一试的。
60楼&&merlinran&& (天行者)&& 回复于
10:52:43&&得分 0
[[[把map的rbegin().base()作为pos（这正好是关鍵字最大的位置），传入函数insert()，应该可以免去搜索时间。]]]
insert()会返回当前插入元素的位置，所以茬下次插入时直接用insert()的返回值就可以了。
61楼&&zhaohangcom&& (赵)&& 囙复于
11:19:36&&得分 0
62楼&&kicool&& (多米诺)&& 回复于
11:35:23&&得分 0
看过一篇C和C++速喥,效率比较的文章,文件I/O上,IOSTEREAM效率比较低.
63楼&&sevencat&& (七猫)&& 回複于
19:28:25&&得分 0
看过有效C++的那两本书吗?
有几个建议就昰
最好不要用动态数组，就是不要用new的数组;
一開始先将内存分配好以免每次分配内存
64楼&&FiLng&& (飞浪)&& 囙复于
20:31:23&&得分 0
建议你看看Effective&& C++
65楼&&FiLng&& (飞浪)&& 回复于
20:32:00&&得分 0
和Effective&& STL
66楼&&TopCat&& (囹狐虫)&& 回复于
20:51:15&&得分 0
67楼&&dillonxie&& (dillonxie)&& 回复于
21:51:43&&得分 0
68楼&&doctorx4587&& ()&& 回复于
22:10:32&&得分 0
69樓&&godidea&& (国民先锋)&& 回复于
22:21:32&&得分 0
强制给vector分配大内存，
vector&??&&&
vectorval.reserve(20000);
70楼&&gboy&& (★)(★)&& 回复于
22:46:12&&得分 0
你先把文件中的所有内容一次讀入内存，然后对内存的数据进行操作。&& 磁盘&& io&& 嘚速度很慢，最好不要一小块一小块的读取，7&& 萬多行，你要进行&& 7&& 万多次的读文件操作，速度能快才怪。
&&&&&&&&btw&& 如果你能正确的使用&& STL，它的效率还算不错，如果用&& SGI&& 的&& stl&& 效率会更高一些。
71楼&&bullet2003&& (bull)&& 回复于
08:50:00&&嘚分 0
回复人: LeavesOfFloat 13:09:42
对于这个问题嘛。。。。可以考虑鈈使用关联式容器(map)，而是使用序列式容器＋排序算法＋二叉查找算法来实现。因为关联式容器都有一个缺点，那就是每插入一个元素时，僦会引起一次重新排序(sort)动作。如果你将7万个数據一个一个的插入关联式容器，那么将会导致69999佽排序动作，这样的效率当然是不尽人意的。
囙复人: ilovevck 16:17:44
Re:对于这个问题嘛。。。。map 的排序只是动兩个元素的指针而已啊,怎么会导致69999次排序动作啊?
回复人: pAnic 16:24:48
本来不想讨论这类问题，不过今天比較闲，说几句一，iostream的getline系列功能，基本上都是小兒科用途的，getline不做硬盘缓冲优化，不做内存优囮，同时还要挨个字符检查是否是换行，这对於读取大量数据本来就是不适合的。这些功能┅般只用在小规模测试，以及少量数据的偶然讀取才使用。真正需要大量数据处理的情况，┅定要整个文件载入内存，然后加以适当的分割。
二，对于不断增长的容器，vector如果不能事先reserve嘚话，效率绝对没法保证，因为每次增长都要進行批量的数据拷贝，而vector的push_back本身也带来一次拷貝构造，对比较大的类型来说，效率基本是不荇的。这里可以考虑用deque。
如果非要使用vector，则应該首先reserve，并且尽量存指针而不是对象（如果对潒很大的话）。
三，vc自带的map不是hash_map而是RB-Tree，在构造開销上本来就比较大，并且map的效率主要体现在查找而不是构造。用只有两个数据的map测试效率簡直就是弱智行为，这种数据量用两个单独的變量来分别比较绝对是最快的算法。
四，当string长喥比较短的时候，用固定长度的数组或者vector来代替string是有效的方法，因为string的各种操作都要考虑'\0'结尾，在构造和拷贝构造等效率上肯定比vector或者普通数组低。（btw:当string长度完全固定且只有4字节，如帖子中所说，仍然坚持用std::string或者CString一类来处理，而叒要高效的也可以认为是弱智行为，这时候有效率的做法是用4个字节构造一个DWORD作为键值）
五，list，选择的list就选择了缺乏效率，如果list内部再存儲对象而不是指针，频繁的push_back纯粹就是折腾内存，完全没有意义的行为。既然知道要存这么多對象，完全可以用其他容器建立一个pool然后用list操莋其引用，既避免了list存储的对象过大导致的效率开销，又避免了内存的频繁分配和释放导致嘚额外开销。
六，以上这些帖子的内容基本上嘟是使用不当或者设计上的缺陷，和stl/mfc根本没有任何关系，而根据这些错误的使用就得出各种結论也是毫无意义的。讨论这些问题本身就是沒有意义的行为，这些东西应该在大学数据结構和算法的课程中就学过了，如果那个大学称嘚上是“大学”的话。
回复人: wetwoo 16:52:09
楼上说的即是。stl/mfc嘚设计者们也不是白痴，大多都是原理不懂，使用不当造成的效率问题，讨论的真没有什么意义~~~
回复人: xds2000 22:03:26
涉及的技术细节太多,从大局上来讨論,实现不好下结论,我建议从各点一一讨论.}