Microsoft Visual C++ 向后兼容性答案

【问题标题】：Microsoft visual C++ backwards compatibilityMicrosoft Visual C++ 向后兼容性
【发布时间】：2011-04-19 15:53:19
【问题描述】：

考虑将 C++ API 定义为一系列 __options(declexport/import) 类。

此外，假设调用者永远不允许在这些类上调用普通的operator new(size_t)。要么是静态工厂方法，要么是特定于类的operator new。并且根据需要在删除大小上做同样的标记（通常只是一个虚拟析构函数）。

现在，如果您使用 VS2010 中的工具编译和链接一个 DLL 和一个 IMPLIB，您可以将那个 implib 和 DLL 交给 VS2005 的用户并期望它工作吗？

这里根本不涉及 MFC。

我将特别感谢任何关于该主题的相对正式的 Microsoft 声明的引用。

【问题讨论】：

您的测试结果如何？
简单案例有效。打哈欠。
那太好了！听起来你做的一切都是正确的。
对我来说不是。我担心（a）一些不起眼的例外情况会爆炸，或者（b）MS保留从我下面拉出地毯的权利。所以我希望能找到比我更早的人来过这里，或者这一切真的有一个明确的“官方”声明。
我的回答保持不变：不要传入特定于版本的实现类型。通过查看MSVC100P.DLL 的导出输出最容易找到此列表。

【解决方案1】：

只要 C++ API 上的名称修饰是相同的（它们是相同的），并且不使用特定于 STL 类型的参数，例如 basic_string 或 std::map，它们的实现可能在编译器版本之间发生了变化（他们有），那么它应该可以工作。

当然，您需要确保使用 /MT 模式（静态链接运行时）编译 DLL，或者在提供的库和链接目标中包含 VS2010 运行时的可再发行组件。

编辑：扩展“不要传入具有特定于版本实现的类型”。通过查看MSVC100P.DLL 的导出输出最容易找到部分列表。

cd %VS100COMNTOOLS%\..\VC\redist\x86\Microsoft.VC100.CRT
DUMPBIN /exports MSVCP100.DLL

下一个问题将是诸如map 或set 之类的仅标头实现，它们在编译器版本之间的底层发生了变化。

这就是为什么强烈建议只在内存区域之间传递标量类型的原因。因此，简单的测试将通过并且是可靠的。

【讨论】：

【解决方案2】：

你没有提到你是否使用过 MFC 来创建 DLL。如果你有，常规的 DLL 应该可以工作，但我不认为扩展应该工作，因为后者链接到 MFC dll。我提供了供你参考的链接。

编辑如果是普通的DLL，应该没有问题。也取决于链接类型。

【讨论】：