分享VC6.0 STL 补丁，随便散分

耍宝王 2010-02-03 04:11:27

这是我昨天无意中发现的，内容出自freefalcon的个人专栏，其中VC6.0的STL库涉及9个头文件，我已经改好了现在放上来，覆盖就好（X:\Program Files\Microsoft Visual Studio\VC98\Include）不过还是建议备份原文件

下载地址：http://download.csdn.net/source/2042973

修正方案使用的是DINKUMWARE公司
原地址中的部分BUG已在VC6.0 sp6中得到修复，以下列出的是未修复的

顺便说一下关于istream头文件的修改，dinkumware上给出的是VC 5.0 的方案，VC 6.0已经修复了这个，但是VC 6.0修改方法和dinkumware不同，dinkumware的修改方案中的有提及原文：Note that V6.0 replaces snextc with stossc. It is an adequate fix, but you can also apply the above patch safely.请自行决定，因此我也没有把istream放上来

以下内容摘自：
freefalcon的个人专栏

Fix to deque
改动相当大，差不多是重写了整个代码。我未作分析。

Fix to fstream
该BUG主要影响效率，从代码可以看出，只有当_Closef不等于_Openf1时才可能执行后面的_Mysb::_Init，这样对于通过 open方式打开一指定文件（函数为_Myt *open(const char *_S, ios_base::openmode _M)）则有不好的性能。

Fix to list
sort方法在元素数量大于等于32768时存在问题，测试代码如下：

Fix to sstream
basic_stringbuf::overflow在处理内存增长时太缓慢，严重影响性能。

Fix to string
问题与istream类似，均为getline处理终止符时有问题。我未对该问题做分析，不知道它在什么情况下出现以及有什么后果。

Fix to vector
该问题不明显，我不清楚它在什么情况下会出现。按照其代码，只有当_First或_Last受到意外改写才可能造成问题。

Fix to xmemory
该问题不易出现，属于编译器的BUG。

Fix to xstring
P.J. STL中的的string采用了copy on write和reference counting技术
实现这一方式的手段是引用计数，为此，P.J. STL采用了一个巧妙的手段，即在分配内存时多申请了一个字节的空间（位于起始处），这一字节被用作引用计数，由此可知，其计数的最大值只能是255，该值用宏_FROZEN表示。
但是P.J. STL并没有考虑引用计数在多线程环境下的同步问题，因此存在潜在的错误。解决这一问题最简单的办法是将_FROZEN的值改为0，即去掉引用计数功能。而完备的方案则需自己动手实现多线程同步。

Fix to xtree
改动较大，对map、multimap、set和multiset存在影响，未作分析

...全文