考虑这种情况： 一个应用程序链接到第 3 方库 A。
A 是使用 MSVC 2008 构建的，并且静态链接（即使用 /MT 构建）到 C 运行时库 v9.0。
该应用程序是使用 MSVC 2005 构建的，并且静态链接到 A 和（使用 /MT）到 C 运行时库 v8.0。
我可以看到这个问题 - 例如，如果在运行时库版本之间的标头中更改了类型。
是否注意保持运行时库标头在版本之间兼容，或者是否应该始终确保所有静态链接的库都链接到相同版本的运行时库？
【问题讨论】：
标签： c++ visual-c++ msvcrt static-linking crt
应该不是问题。每个库都链接到自己的运行时，并且大部分功能独立于进程中的其他库。当库 ABI 定义不正确时，就会出现问题。如果任何类型的堆分配对象在一个库中分配，通过库边界并在另一个库中“释放”，则会出现问题，因为正在使用不同的堆管理器从用于分配的堆管理器中释放块它。
任何类型的 c-runtime 定义的结构、对象或实体都不应跨越可能使用不同运行时版本的边界传递：- 例如，从一个库获得的 FILE* 对不同的库没有意义链接到不同的运行时。
只要库 API 仅使用原始类型，并且不要尝试 free() 传入指针，或将指针传递到他们希望应用程序（或其他库）释放的内部 malloc() 内存() 你应该没事。
如果混合 c 运行时，很容易陷入“任何事情都可能出错”的 FUD，但您必须记住，库和动态库 (.so / .dll / .dylib) 传统上是在多种语言：允许用 asm、c、c++、fortran、pascal 等编写的代码通过有效的 CPU 高效二进制接口进行通信。
为什么当 C 链接到 C 时突然恐慌？
【讨论】：
这是一个非常糟糕的计划。避免。要么在 2005 年重新编译库，要么在 2008 年编译应用程序。
【讨论】：
根本不是一个好主意。您无法控制运行时库所做的假设以及它们如何实现某些类型。这更有可能造成不洁的混乱。
【讨论】：