Vc6 STL patch description

Address: http://www.dinkumware.com/vc_fixes.html

Fix to Algorithm

The two local variables in the internal function _ buffered_merge are not initialized, and vc6 has been corrected.

Fix to deque

The changes are quite large, and the entire code is almost rewritten. I did not perform analysis.

Fix to fstream

This bug mainly affects efficiency. It can be seen from the code that the following _ mysb: _ init can be executed only when _ closef is not equal to _ openf1, in this way, opening a specified file (the function is _ MYT * Open (const char * _ s, ios_base: openmode _ m) has poor performance.

Fix to istream

The Getline function is faulty when processing the Terminator. vc6 has been corrected.

Fix to list

The sort method has a problem when the number of elements is greater than or equal to 32768. The test code is as follows:

Void test_list ()
{
Cout <"list: Sort Test..." <Endl;

List <int> Li1, li2; // two lists are used for comparison.
Const int COUNT = 32768; // number of elements,> = 32768 a bug will occur

Vector <int> VI; // vector is used to generate random sequences.
Vi. Resize (count );
For (INT I = 1; I <= count; ++ I)
{
VI [I-1] = I;
Li1.push _ back (I );
}
Srand (time (0 ));
Random_shuffle (VI. rbegin (), VI. rend ());

// Copy (VI. Begin (), VI. End (), ostream_iterator <int> (cout ,""));

Li2.resize (count );
Copy (VI. Begin (), VI. End (), li2.begin ());
Li2.sort (); // sort
// Copy (li2.begin (), li2.end (), ostream_iterator <int> (cout ,""));

Bool res = (Li1 = li2); // compare the two
Cout <"elements_count =" <count <", result =" <res <Endl;
}

Fix to memory

Auto_ptr has a problem when assigning values. vc6 has been corrected.

Fix to sstream

Basic_stringbuf: overflow is too slow to process memory growth, seriously affecting performance.

Fix to string

The problem is similar to that of istream. It is a problem when Getline processes the Terminator. I did not analyze the problem, and I don't know under what circumstances it will appear and what consequences it will have.

Fix to Vector

This problem is not obvious. I don't know under what circumstances it will appear. According to the Code, only when _ first or _ last is accidentally rewritten can the problem be caused.

Fix to xmemory

This issue is not easy to see and is a compiler bug.

Fix to xstring

The string in P. J. STL adopts the copy on write and reference counting technologies. For the following code:

String S1 = "ABC"; // Statement 1
String S2 = S1; // Statement 2
S2 = "123"; // Statement 3

When Statement 2 is executed, there will be no two "ABC" copies. Instead, S2 shares the memory with S1.

When Statement 3 is executed, the S2 value is rewritten, and memory is allocated separately.

The method to implement this is to reference the count. For this reason, P. j. STL uses a clever method, that is, when the memory is allocated, an extra byte of space (located at the beginning) is applied. This byte is used for reference counting. From this we can see that, the maximum value of the counter can only be 255, which is expressed by macro _ frozen.

However, P. J. STL does not consider the synchronization problem of reference counting in multi-threaded environments, so there are potential errors. The simplest way to solve this problem is to change the value of _ frozen to 0, that is, to remove the reference count function. A complete solution requires you to implement multi-threaded synchronization by yourself.

Fix to xtree

The changes are large and have an impact on map, multimap, set, and Multiset. No analysis is made.

(Freefalcon on)