原文地址:http://www.dinkumware.com/vc_fixes.html
The following bug fixes correct problems in the Standard C++ Library that accompanies Microsoft Visual C++ V5.0 and V6.0. Each replacement header file supplied here is represented as a .txt file, so you can view it directly with a web browser. You can also install the replacement file directly from the browser while you are viewing it -- simply select File/Save As File and store the file with the appropriate name in the include directory. YOU ARE STRONGLY ENCOURAGED TO SAVE THE EXISTING HEADER BEFORE OVERWRITING IT.
For example, to replace the header <deque>
in a typical VC++ V5.0 installation, choose the directory:
c:/Program Files/DevStudio/VC/include
and save the file with the name deque
. Note that some browsers insist on saving the file with the name deque.txt
, in which case you will have to rename the file after saving it from the browser.
Be warned that updating a header file does not necessarily trigger a recompilation. You may have to force a rebuild to see the effect of a change.
Note also that some header-file information is captured in DLLs supplied by Microsoft. If you encounter a conflict, you must either avoid using the DLL (by linking statically) or rebuild the offending DLL. We still can supply no information on how to rebuild the standard DLLs shipped with VC++. (Microsoft insists that it's too difficult to describe.)
It is always a good idea to apply the latest Microsoft service pack to upgrade your compiler. Many problems quietly disappear when you do so. For example, you can now get V5.0 SP3 and V6.0 SP3.
The files presented here are copyright ?1995-2000 by P.J. Plauger. All rights reserved. They are for use only in conjunction with a valid license for Microsoft Visual C++ V5.0 or V6.0. Microsoft Corporation is in no way involved with the production or release of these files. The files are offered on an ``as is'' basis. DINKUMWARE, LTD. AND P.J. PLAUGER MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THESE FILES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. DINKUMWARE, LTD. AND P.J. PLAUGER SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING THESE FILES.
<algorithm>
The internal template algorithm _Buffered_merge
(two versions) fails to initialize local variables in two places. Change the code as indicated by the comments:
if (_D2 < _D1) {_D1n = _D1 / 2, _D2n = 0; // clear _D2n _Fn = _F; advance(_Fn, _D1n); _Ln = lower_bound(_M, _L, *_Fn); _Distance(_M, _Ln, _D2n); } else {_D1n = 0, _D2n = _D2 / 2; // clear _D1n _Ln = _M; advance(_Ln, _D2n); _Fn = upper_bound(_F, _M, *_Ln); _Distance(_F, _Fn, _D1n); }
And for the version with predicate:
if (_D2 < _D1) {_D1n = _D1 / 2, _D2n = 0; // clear _D2n _Fn = _F; advance(_Fn, _D1n); _Ln = lower_bound(_M, _L, *_Fn, _P); _Distance(_M, _Ln, _D2n); } else {_D1n = 0, _D2n = _D2 / 2; // clear _D1n _Ln = _M; advance(_Ln, _D2n); _Fn = upper_bound(_F, _M, *_Ln, _P); _Distance(_F, _Fn, _D1n); }
<deque>
The header <deque>
(updated 18 October 1999 to V2.33, the latest shipped version) presented here corrects a problem with the representation of the iterator that designates the end of the controlled sequence. If the sequence exactly fills the last allocated block, incrementing the iterator that designates the last element can yield a value that does not match the value returned by end()
. The larger the elements stored in the container, the more likely this situation will arise.
The fix is to ensure that every iterator has just one possible representation. For added security, the ends of the container are now guarded with null map pointers. It is no longer possible to step an iterator off either end of the sequence. (Such protection is not required by the C++ Standard, but it makes for nicer failure modes in buggy code.)
<fstream>
(Added 13 October 1999.) The header <fstream>
defines template class basic_filebuf
(among other things. Its member function _Init
contains a bug that causes files opened by name to disable buffering unnecessarily, resulting in a serious degradation of performance. Change the test:
if (_Fp != 0 && !_Closef && sizeof (_E) == 1)
to:
if (_Fp != 0 && sizeof (_E) == 1)
to eliminate this problem.
<istream>
The header <istream>
contains a definition for member function basic_istream::getline
. It has a lookahead problem -- typing a delimiter to end the input doesn't return control until you type yet another character. Change the code as indicated by the comment:
else if (_C == _Di) {++_Chcount; rdbuf()->snextc(); // replace snextc with sbumpc break; }
Note that V6.0 replaces snextc
with stossc
. It is an adequate fix, but you can also apply the above patch safely.
<list>
(updated 7 July 1998) Both versions of the member function list::sort
misplace elements if asked to sort a container with more than 32,768 elements. To fix the first version, change the code as indicated by the comment:
if (_I == _MAXN) _A[_I].merge(_X); // SHOULD BE _A[_I - 1].merge(_X);
Also change the corresponding line in the second version:
if (_I == _MAXN) _A[_I].merge(_X, _Pr); // SHOULD BE _A[_I - 1].merge(_X, _Pr);
You might also consider increasing _MAXN
from 15 to, say 25. That way, you would have to sort a list of more than 32 million elements, instead of 32 thousand, before the performance begins to degrade.
<memory>
Template class auto_ptr
creates two owners for an object if you copy an auto_ptr
object back to a previous owner that still stores the same object pointer. To eliminate this problem, change the code in auto_ptr::operator=
as indicated by the comment:
else if (_Y._Owns) _Owns = true; // _Owns = true, _Y.release();
Note that this template class has been redesigned more than once since this version of the library was frozen. No attempt is made here to track those changes.
<sstream>
(Added 12 November 1999.) Class basic_stringbuf
grows its buffer by fixed-size increments, which can be very slow if the buffer gets very large. To grow the buffer exponentially, replace the line in basic_stringbuf::overflow
that reads:
size_t _Ns = _Os + _Alsize;
with:
size_t _Ns = (_Os < _Alsize) ? _Os + _Alsize : 2 * _Os + 1;
<string>
The header <string>
contains a definition for template function getline
. It has a lookahead problem -- typing a delimiter to end the input doesn't return control until you type yet another character. Change the code as indicated by the comment:
else if (_Tr::eq(_C, _D)) {_Chg = true; _I.rdbuf()->snextc(); // replace snextc with sbumpc break; }
<vector>
The header <vector>
sometimes fails to extend a vector properly. In two versions ofinsert
, change the code as shown:
_Destroy(_First, _Last); allocator.deallocate(_First, _End - _First); _End = _S + _N; _Last = _S + size() + _M; _First = _S; } _Destroy(_First, _Last); size_type _O = size(); // add this statement allocator.deallocate(_First, _End - _First); _End = _S + _N; _Last = _S + _O + _M; // was _Last = _S + size() + _M; _First = _S; }
<xmemory>
Template class _Destroy
has an unfortunate interaction with a bug in the VC++ compiler. It gets confused if you ask it to destroy an object of a class that defines the name _Ty
. (Template class complex
is one such creature.) The best workaround is to replace the template parameter _Ty
with a really strange name, as in:
// TEMPLATE FUNCTION _Destroy template<class _Xyzzy> inline void _Destroy(_Xyzzy _FARQ *_P) {_DESTRUCTOR(_Xyzzy, _P); }
<xstring>
The header <xstring>
(original 25 May 1998) presented here corrects a problem with string assignments. Assigning a shorter sequence to an existing string can cause the old string to be copied in full to the newly allocated area, thus causing a storage overwrite, and an occasional storage leak as a result. In rarer circumstances, a string is partially altered by a replace
member function before the copy on write occurs, thus causing changes to an apparently unrelated string object.
The fix is a small but significant change to the private member function _Grow
. Several calls to _Freeze
, to force a copy on write, are also added.
Please note that this implementation is still not as thread safe as it should be, because of the reference-counted implementation. A write to a ``copy'' of a string in one thread can confuse a read of that string in another thread, because the two still secretly share the same representation. One way to ensure that the non-const string str
has a private representation is to call str.begin()
. (By creating a mutable iterator into the string, you rule out sharing of representations.) Another way is to disable reference-counting altogether, making string operations thread safe. Simply change the value of _FROZEN
to zero:
enum _Mref {_FROZEN = 255}; // set to zero to disable sharing
<xtree>
The header <xtree>
(original 25 June 1998) presented here eliminates all need for thread locks and corrects a number of thread-safety issues for template classes map
, multimap
, set
, and multiset
. It also solves some nasty problems with sharing these classes across DLLs. Note that no attempt has been made to retrofit the changes needed to make these template classes exception safe in the sense required by the final C++ Standard. (The headers map
and set
once presented here have been dropped as of 4 April 1999 -- they were effectively unchanged over the shipped versions.)
strftime.c
The Microsoft C library file strftime.c
(original 28 March 2000) fails to supply locale information needed for the %X
conversion specifier used by template class time_put
. To fix the problem, add the missing line shown below to the function _Gettnames
. Change the code from:
s += strlen(strcpy(s, pt->ww_ldatefmt)) + 1; pn->ww_timefmt = s; }
to:
s += strlen(strcpy(s, pt->ww_ldatefmt)) + 1; pn->ww_timefmt = s; strcpy(s, pt->ww_timefmt); }
NB: You need to make this change even if you licensed the v3.08 upgrade library from Dinkumware. We do not supply a replacement for it.