闲侃名家名作

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

首先声明写作此文绝非因为我是愤青，也不是因为我认为自己有多牛，更不是对文中所提到的人有什么不尊重（其实这些都是我比较崇拜的人）。只是想说，只要是人就可能犯错，所以永远不要丢了怀疑权威的勇气。顺便从侧面回应一下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运行时库不使用进程缺省堆。