闲侃名家名作

类别:VC语言 点击:0 评论:0 推荐:

 

首先声明写作此文绝非因为我是愤青,也不是因为我认为自己有多牛,更不是对文中所提到的人有什么不尊重(其实这些都是我比较崇拜的人)。只是想说,只要是人就可能犯错,所以永远不要丢了怀疑权威的勇气。顺便从侧面回应一下mikeczy对我的评价,他说“狂犬吠日之蠢材,不要动不动就使用“驳”字。”本人此文可能尚有错漏,还请方家斧正。

 

       其一:候捷先生的大作《STL源代码剖析》中,99页有这么一句话:“换句话说,当客端调用distance()并使用Output Iterators或Forward Iterators或Bidirectional iterators时统统都会传递调用Input Iterator版的那个__distance()函数。”这句话应该就是错的,因为Output Iterators和Input Iterator在继承上没有任何关系,所以怎么也不能从

__distance( __first, __last, output_iterator_tag) 推导出要调用

__distance(__first, __last, input_iterator_tag)。不知诸君以为然否?

 

       其二:Feng Yuan是《windows 图形编程》的作者,由于此书主讲GDI模块,可能有些人并没有读过。当然读过的人应该都会有种叹为观止的感觉。但在第一章里讲到用修改导入导出表来挂接函数时,作者给出的代码是这样的:

           // find the entry with the function name

              for (unsigned i=0; i<pExport->AddressOfNames; i++)

                     if ( stricmp(pProcName, RVA2Ptr(pNames[i]))==0 )

                     {

                            // get the corresponding ordinal

                            ord = pExport->Base + pOrds[i];

                            break;

                     }

为了下面的讲解,我对此做简单的说明。在这段代码中,pExport指向欲挂接模块的导出表,即IMAGE_EXPORT_DIRECTORY结构的指针,而pProcName为要挂接的API函数的名字, pNames这是 由IMAGE_EXPORT_DIRECTORY 的成员变量AddressOfNames转换来的实际地址。RVA2Ptr是把RVA地址转换为真实地址的函数。由此可以看出这段代码是求欲挂接函数所对应的序数。但这里边有个小问题,循环的终止条件有问题,至少在逻辑上不对。pExport->AddressOfNames是个RVA,i小于一个RVA是没有意义的,虽然这个RVA通常都足够大,所以程序运行上并不见得会有问题。实际上应该是i<pExport-> NumberOfNames,因为NumberOfNames才指明导出函数的数目。

 

其三:虽然大家都对microsoft抱有某种逆反,而microsoft的产品也确实暴露出一些问题,但我们仍不得不承认,他的程序员队伍是顶级的。那么我们现在说一下microsoft的摇钱树Word,在Word 中你可以从菜单中选格式,再选背景,再选水印,而后指定相应的文本,这样就会在你的文档中加入诸如公司机密一类的水印。可microsoft的实现有没有问题呢?你在文档中画一个方框,或者导入一个图形你就知道了,此时水印被完全覆盖了。公司机密也就变成了公司密一类的东西。其实这个问题真的很容易解决,只要先把文本转为路径,并确保输出水印的函数总在重画页面时最后被调用即可。如果我没弄错的话,microsoft内部是用Bezier曲线加上填充硬画出来的,并且对添加水印的时机把握的并不好,还真是“牛人”自有“牛人”的方法。

 

其四说一下大名鼎鼎的SGI STL。在向下进行之前,我们来看段程序。这段程序很简单,就是在windows操作系统下,枚举系统缺省堆的情况。最终把堆中各个块的信息和整个堆的totalsize和freesize输出。

 

#include <windows.h>

#include <Tlhelp32.h>

#include <iostream>

#include <deque>

#include <vector>

using namespace std;

 

typedef vector<int> VINT;

typedef deque<int>  DINT;

 

int main(int argc, char* argv[])

{

HANDLE hSnapShot=CreateToolhelp32Snapshot(TH32CS_SNAPHEAPLIST,

GetCurrentProcessId());

       HEAPLIST32  heaplist32;

 

       heaplist32.dwSize=sizeof(HEAPLIST32);

 

       BOOL bRet=Heap32ListFirst(hSnapShot,&heaplist32);

      

       DINT ui;

 

       for(int i=0; i<4096; ++i)

              {

                     ui.push_back(1);

              }

       ui.clear();

 

       if(bRet)

       {

              HEAPENTRY32  he32;

              DWORD totalsize=0,freesize=0;

 

              he32.dwSize=sizeof(HEAPENTRY32);

 

              Heap32First(&he32,heaplist32.th32ProcessID,heaplist32.th32HeapID);

 

              if(he32.dwFlags & LF32_FREE)

                     freesize +=he32.dwBlockSize;

             

              totalsize +=he32.dwBlockSize;

 

cout<< "The information of first block: " << "Blocksize: "<<he32.dwBlockSize<<"\t Address: "<<(LONG)he32.dwAddress<<endl;

 

              while(Heap32Next(&he32))

                     {

cout<< "The information of block: " << "Blocksize: "<<he32.dwBlockSize<<"\t Address: "<<(LONG)he32.dwAddress<<endl;

 

                            totalsize +=he32.dwBlockSize;

 

                            if(he32.dwFlags & LF32_FREE)

                            freesize +=he32.dwBlockSize;

 

                     }

 

              cout<< "the total size of the heap is: " <<totalsize<<endl;

              cout<< "the free  size of the heap is: " <<freesize <<endl;

              cout<< "the commited  size of the heap is: " <<(totalsize-freesize) <<endl;

 

       }

 

       return 0;

}

我们先在SGI STL下来运行这段程序。你会惊奇的发现注掉和不注掉ui.clear()结果是一样的,在我的机器上结果如下:

The information of first block: Blocksize: 16836       Address: 7143544

The information of block: Blocksize: 3008       Address: 7160384

The information of block: Blocksize: 5440       Address: 7163396

The information of block: Blocksize: 5776       Address: 7168840

The information of block: Blocksize: 6128       Address: 7174620

The information of block: Blocksize: 1312       Address: 7180752

The information of block: Blocksize: 4144       Address: 7182068

The information of block: Blocksize: 1005780  Address: 7186224

The information of block: Blocksize: 0     Address: 8192008

The information of block: Blocksize: 320  Address: 8192012

The information of block: Blocksize: 2096       Address: 8192336

The information of block: Blocksize: 1328       Address: 8194436

The information of block: Blocksize: 316  Address: 8195776

the total size of the heap is: 1052484

the free  size of the heap is: 1006096

the commited  size of the heap is: 46388

奇怪之处在于最后一行,按道理对ui调用clear()之后,ui所占用的堆空间应该被释放了(不要忘了容器内部是在堆中分配内存的),这样两次的结果就我输出结果中的commited  size一项而言绝对不应该一样。如果你做进一步尝试,把对ui的定义和push_back的操作放入另外一个函数里,让ui得以自动析构,你将得到基本相同的结果,ui所占用的堆空间并不会被释放。这也就意味着,在某种特定情况下内存被“泄漏”(与通常的内存泄漏不同所以用引号)了。我们再做一些进一步的试验,把SGI STL换成VC自带的STL。你会发现结果与SGI STL有根本的不同,在执行ui.clear()或者析构函数被调用后进程缺省堆的空间回复到了对ui进行push_back以前的水平。

 

原因何在呢?如果你读过SGI STL的源代码,并仔细的分析了SGI对分配器的实现(1),你会发现在缺省的情况下,SGI STL针对两种情况运用两种不同的内存分配机制。如果你分配的内存块大于128字节,那么分配器直接用malloc进行分配,否则将启用一种叫做Memory Pool(2)的机制,而在这种机制下内存的释放等价于把内存放回Memory Pool,而不是真的还给系统。而又由于SGI STL中并没有对Memory Pool中内存进行释放或动态缩减的机制,所以导致Memory Pool中的内存只能随着进程的释放而被释放。所以也就出现了上述的情况。由于SGI STL以_USE_MALLOC(STLport中是_STLP_USE_MALLOC)宏来决定是否启用Memory Pool机制我们可以试着在定义了此宏的基础上再进行一次检查。你将发现这回ui容器所占用的内存得到了释放。也许Memory Pool技术在某种特定的情况下将为程序带来非常大的收益,但在windows平台下,由于他有可能导致堆内存的隐性消失,本人建议慎用(尤其是在服务进程中,这种内存消耗对系统的影响可能就非常的巨大)。

 

我要重复一下开篇时的话,人是一种很容易犯错的生物,很不幸牛人也是人,只不过较少犯错而已。同样的,根本不是牛人的我也就更不敢肯定我文中所说的全是对的,我诚恳的希望大家给予批评和指正。上帝也许是有的,但不在我们身边,所以莫要失去怀疑的勇气。

 

 

注1候捷老师在《STL源代码剖析》一书中对此有详尽的分析。

注2《The C++ Programming Language》第三版对此有一个简单的实现。

注3当对容器执行push_back时最好确保容器所占用的空间不要超过1M,因为进程缺省堆为1M,超过1M后系统将对进程缺省堆进行扩充,这样有可能造成被统计数据显得混乱。比如可能出现用的越多,空闲越多的情况。

注4:检验heap代码给出的结果是对应于98系统的。2000下要想看到这种变化则要把进程内所有堆都进行枚举。因为2000下C运行时库不使用进程缺省堆。

本文地址:http://com.8s8s.com/it/it1517.htm