混合使用不同版本的 Visual Studio 2002 及更高版本构建的 C 代码静态库
我有一个 C 和 Fortran 例程的静态可链接库，使用 Visual Studio 2002 C (v7.0) 编译器和 Intel Fortran 9.0.018 编译器编译并链接在一起。
我的库中的 C 代码调用并链接到 Microsoft C-RunTime (MSCRT) 2002 静态库（单线程）。 我相信 2002 CRT 库的实际版本号是 v7.0
我将将此静态库称为“vs2002if9.lib”
我可以使用任何更高版本的 Visual Studio（2003、 2005 或 2008）而不用担心调用程序在 C 运行时调用方面的行为？
或者我是否因混合 CRT 静态库版本而产生问题？
如果我将“vs2002if9.lib”提供给第 3 方软件开发人员会怎么样？ 我对他们提出什么要求？
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.
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
I will refer to this static library as "vs2002if9.lib"
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?
Or am I creating problems by mixing version of the CRT static libs?
What if I provide my "vs2002if9.lib" to 3rd party software developers? What requirements am I imposing on them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
过去，混合 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].
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.