This is a problem that has plagued us for a long time.
I have been cheated for a long time, thinking that STL is a template library, all classes and functions are inline, and no additional dependencies are required for programs written using STL. In this way, I prefer to use string rather than cstring. Obviously, if I only use a string function, I need to build a mfc42.dll of nearly 1 MB for my program. (I am also depressed when I use a static link to MFC: I didn't write a few lines of code. Why is the compiled program so big ?)
Later, we found that using string is not as good as using cstring. Because at least 98 systems are self-contained with mfc42.dll. However, msvcp60.dll, one of the two libraries required by string (msvcrt. dll and msvcp60.dll), does not exist on some systems. Find the number of posts on the Internet and find msvcp60.dll.
It's not just string. msvcp60.dll is also used when map and set are used.
To solve this problem, I searched the Chinese web page on Google and did not see any discussion about it. The solution is to download a msvcp60.dll.
Later I found a clue on a foreign website (web site http://www.dinkumware.com/vc_fixes.html)
The original article will not be excerpted. The general idea is that there is a problem in the STL Implementation of VC. In particular, the implementation of <xtree> depends on DLL because the self-produced thread is mutually exclusive. After I replaced the xtree of the local machine with the version on the website, set and map finally got rid of msvcp60.dll. The remaining string problem is not solved.
Then I saw an article on the Microsoft website about the crash of string on a multi-processor machine (http://support.microsoft.com/default.aspx? SCID = KB; en-US; 813810). It is very simple to make the implementation of string independent of msvcp60 when dynamically linking the Runtime Library, find # ifdef _ DLL… in <sting> and <xstring> respectively... # Endif. Just comment out the content.
After doing this, the string does not depend on msvcp60, but the compiled EXE file still depends on msvcp60.
It seems that you have to do it yourself. Through the dependency tool, I found that my EXE imported the STD: _ xlen function of msvcp60, so I searched all the files in the vc98 directory, in vc98/CRT/src/string. the implementation of the function is found in CPP:
_ Std_begin
// Report a length_error
_ Crtimp2 void _ cdecl _ xlen ()
{_ Throw (length_error, "string too long ");}
// Report an out_of_range Error
_ Crtimp2 void _ cdecl _ xran ()
{_ Throw (out_of_range, "invalid string position ");}
_ Std_end
So I found a place in my project and wrote the following code:
Namespace STD {
Void _ xlen ()
{
}
Void _ xran ()
{
}
};
Then compile and OK, and finally get rid of msvcp60.dll.
However, the method I used has not been strictly tested and it is not guaranteed that it will not cause other problems. If you are interested, please try it yourself.
