There are a lot of C++ libraries (most?) that come with special binaries built for each Visual C++ version (2003, 2005, 2008, 2010).
What's the problem about linking a C++ library built for Visual C++ 2008 with Visual C++ 2010?
There are a lot of C++ libraries (most?) that come with special binaries built for each Visual C++ version (2003, 2005, 2008, 2010).
What's the problem about linking a C++ library built for Visual C++ 2008 with Visual C++ 2010?
Each Visual Studio version carries an updated (and different) version of the C and/or C++ runtime. This msdn page (under: "What problems exist...") explains quite nicely what the issue is. What is described there for msvcrt.dll <-> msvcrt10.dll is valid for every msvcrtXX.dll there is.
It should not present any noteworthy issues, but using the version of the binary for the appropriate version of VS is recommended.
The usual problem is that code generated with different versions of Visual Studio use a different version of the run time libraries.
Depending on how the library is designed this can often cause problems because there are multiple versions of (e.g.) allocation and deallocation functions and it can be easy to get heap errors when a pointer allocated in one run time library is passed to a deallocation function from a different one. This can happen whether the run time libraries are linked dynamically or statically.
Even if this issue is avoided by good library design it is still inefficient to have multiple C heaps in the same program.
There are other potential issues with run time library features that rely on statically held information such as srand
and rand
, locales and ugly legacy functions such as strtok
.
Even when it is possible to link across different versions of Visual Studio it is usually a lot safer not to.