混合使用Visual Studio 2002和更高版本的不同版本构建的C代码静态库
我有一个使用Visual Studio 2002 C(v7.0)编译器和Intel Fortran 9.0.018编译器编译并链接在一起的C和Fortran例程的静态可链接库.
I have a static linkable library of C and Fortran routines compiled and linked together using the Visual Studio 2002 C (v7.0) Compiler and the Intel Fortran 9.0.018 Compiler.
我的库中的C代码调用并链接到Microsoft C-RunTime(MSCRT)2002静态库(单线程).我相信2002 CRT库的实际版本号是v7.0
The C code in my library calls and links to the Microsoft C-RunTime (MSCRT) 2002 static libraries (single-threaded). I believe the actual version number of the 2002 CRT libraries is v7.0
我将此静态库称为"vs2002if9.lib"
I will refer to this static library as "vs2002if9.lib"
我可以使用任何更高版本的Visual Studio(2003、2005或2008)安全地静态链接到我的"vs2002if9.lib"，而不必担心调用程序在C运行时调用方面的行为吗?
Can I statically link to my "vs2002if9.lib" safely using any later version of Visual Studio (2003, 2005 or 2008) without any worries about how the calling program behaves regarding the C runtime calls?
还是我通过混合CRT静态库的版本来创建问题?
Or am I creating problems by mixing version of the CRT static libs?
如果我向第三方软件开发人员提供"vs2002if9.lib"怎么办?我对他们有什么要求?
What if I provide my "vs2002if9.lib" to 3rd party software developers? What requirements am I imposing on them?
过去，混合C运行时对我不起作用.我可以看到此工作的唯一方式{也许是}如果您完全隔离了静态链接的C运行时边界内的堆栈/堆的使用[没有任何东西可以通过参数跨越边界，那么vs2009if9的值是多少.lib提供].
Mixing C runtimes hasn't worked for me in the past. The only manner in which I can see this working {maybe} is if you're completely isolating the use of the stack/heap within the boundaries of the statically linked C-Runtime [nothing crosses boundaries via parameters but then what value is your vs2009if9.lib providing].
作为一个例子，如果您要在应用程序内分配一个指针[heap memory]并将该指针传递给您提供的库，应该使用哪个堆管理器?正确的答案是管理指针的堆管理器，但是您的库不知道其他堆管理器.如果您的库分配了供应用程序使用的内存，这将变得更糟，并且应用程序有责任使用提供的指针来释放/删除内存(糟糕的设计是可以的，但仍然可能).再次，将使用错误的堆管理器.
As an example, if you're to be allocating a pointer [heap memory] within the application and passing this pointer to the library you provided, which heap manager should be used? The correct answer is the heap manager managing the pointer, but your library won't know about the other heap manager. It gets uglier if your library allocates memory for use by the application and it's the applications responsibility to free/delete using the provided pointer (bad design yes but still possible). Again, the wrong heap manager will be utilized.