我知道我们不应该混合使用不同版本的MSVC ++编译的代码，除非与COM进程内服务器完全隔离语言运行时。
但是有些人认为他们可以，并且转发兼容性不是你能提前几年保证的。特别是，该库使用的方案（在2006年）允许一个DLL在具有不同编译选项和RTL动态/静态选择的调用者之间工作，因为动态库总是被命名为msvcrt.dll。现在情况并非如此，因此处理它具有挑战性。但这不是发布的原因。
每个人都会考虑堆函数（malloc，free，operator new等）以及指向DLL边界的指针传递。但是我看到了其他一些根本没有解决的问题。也就是说，头文件使用std::type_info来存储类型化的值（类似于locale facets或Boost.Any），因此隐含的假设是调用者（使用VS10）可以创建包含{{1的类的实例值和预构建DLL（使用一些旧版本的编译器）可以理解它们。
我回想一下之前std::type_info的实现，它使用低效的字符串比较来处理链接器边界。但这只是允许重复的静态常量被视为等效 - 它仍然要求type_info的底层实现是相同的！
所以，是否有人碰巧知道，如果其中字段的结构和解释的实现已经改变或仍然相同，对于不同版本的Visual所提供的不同版本的RTL工作室？即使没有明确的答案，我也希望以任何方式听取经验。
我还在标题中看到type_info的使用。 ＆LT;叹息＆GT;
答案 0 :(得分：1)
我发现在Visual Studio 2005（版本8）和VS 2010（版本10）之间的std::string，在调试版本中，与不兼容。特别地，数据指针的位置是不同的。因此，使用VS 2005编译的代码无法正确解释由VS2010创建的std::string。
我确定发布版本的故事也是如此。我记得std::string特别是与微软库中的STL容器不同，它与某些运行时检查选项更加兼容，所以它不仅仅是编译器开关的细节 - 尽管这始终是兼容性问题即使C ++编译器版本相同！
我没有了解std::type_info，但其中一个问题足以拒绝兼容性。
我想指出，要避免实际传递字符串并使用ABI兼容的调用有一个隐藏的问题：默认参数。默认参数由调用者自动构造和传递，当您移植旧代码或其他东西时，您可能不会意识到存在这样的可选参数。
请注意那些不透明的预构建产品的DLL，即使业务团队因某种原因发现它具有吸引力。十年后，“他们”可能不再支持该产品，并且随着意外情况的变化，前向兼容性计划将逐渐失败。