问题标签 [binary-compatibility]

我很好奇编译器生成的默认构造函数和析构函数是否是内联的，因为无论哪种方式我都可以证明它是合理的。一方面，您希望默认构造函数/析构函数不是内联的，以便稍后添加它们不会破坏 ABI（因为在只有默认值时编译的目标文件将内联生成的定义而不是您定义的定义）。另一方面，对于 C++ 编译器来编译 C 代码的性能与使用 C 编译器编译时一样好，它不能为每个分配的结构添加构造函数/析构函数调用，而在 C++ 中，类之间的唯一功能差异并且结构应该是默认的访问保护。也许链接器以某种方式解决了这个问题？也许答案因编译器而异？

这个问题的结果：如果我在 C++ 中有一个 POD 结构，理论上我可以通过自己定义空的内联构造函数/析构函数来代替默认值，从而在某些编译器下受益吗？

考虑以下 C++ 代码：

现在假设这段代码被放在一个共享库中，供第三方应用程序使用。

X我的问题是：如果我在（例如）末尾添加另一个成员int c，并在 中对其进行初始化，调用中断foobar()的现有应用程序会吗？foobar()请注意，这是关于二进制兼容性，而不是源代码兼容性。

我目前正在为 Windows 开发一个 C++ 库，它将作为 DLL 分发。我的目标是最大化二进制互操作性；更准确地说，我的 DLL 中的函数必须可以从使用多个版本的 MSVC++ 和 MinGW 编译的代码中使用，而无需重新编译 DLL。但是，我很困惑哪种调用约定最好，cdecl或者stdcall.

有时我会听到诸如“C 调用约定是唯一保证跨编译器相同的”之类的声明，这与“对 的解释存在一些变化cdecl，特别是在如何返回值方面”之类的声明形成鲜明对比。这似乎并没有阻止某些库开发人员（如libsndfile）在他们分发的 DLL 中使用 C 调用约定，而没有任何明显的问题。

另一方面，stdcall调用约定似乎定义明确。据我所知，基本上所有 Windows 编译器都必须遵循它，因为它是用于 Win32 和 COM 的约定。这是基于这样的假设，即不支持 Win32/COM 的 Windows 编译器不会很有用。论坛上发布的许多代码片段都将函数声明为，stdcall但我似乎无法找到一篇清楚地解释原因的帖子。

那里有太多相互矛盾的信息，我运行的每次搜索都会给我不同的答案，这并不能真正帮助我在两者之间做出决定。我正在寻找一个清晰、详细、有争议的解释，说明为什么我应该选择一个而不是另一个（或者为什么两者是等价的）。

请注意，这个问题不仅适用于“经典”函数，还适用于虚拟成员函数调用，因为大多数客户端代码将通过“接口”与我的 DLL 交互，纯虚拟类（遵循此处和此处描述的模式）。

首先是一些介绍：我目前正在研究 C++ 兼容性，这意味着能够运行具有不同编译器选项的项目。因此，我使用一个发布 DLL 和一个链接到该其他项目的调试应用程序进行测试。大多数问题都是在使用 STL 时出现的，所以我必须确保两个项目都只使用它们自己的 STL 版本。这就是为什么我有一个包装类，它可以由 std::vectors、std::lists 等构建，但只包含一个完全兼容的数组。现在我可以将值包装在一个数组中，并在另一端将它们解包到一个有效的 STL 对象中。

现在更接近这个问题：有些类包含 STL，但也需要包装到一个数组中。所以我也必须包装内部 STL 对象，这意味着添加一个标签并将其保存在关联的数组元素旁边。

构建这个包装类完全没有问题，但解压它会在向量类中出现访问冲突而崩溃：

那一刻的执行代码是这样的：

奇怪的是我正在解压一个 std::list 但它在 std::vector 中崩溃了。查看对象我有一个由 std::vector 包含的类，而这个类包含一个没有 STL 的基本类的 std::list。所以拆包意味着将外部数组复制到 std::vector 中，将每个内部数组复制到 std::list 中。

此错误仅在我使用不同的编译器选项时发生，在同一个项目中打包和解包工作得很好。

我真的希望任何人都可以帮助我，因为我不知道。

问候

是否可以使用 j2me Polish 让一个 jar 文件在多个手机上运行？

基本上我们希望有二进制兼容性，不希望不同的手机有不同的构建，同时我们需要有好的用户界面

我们确实有 3 个 optino 1. lwuit，2. Polish 3. 定制开发，我们想使用 Polish，但显示初始 hack，我们需要为单独的设备构建它。

任何线索/指针？

拉克西特

我可以将纯虚拟函数（在基类中）更改为非纯函数，而不会遇到任何二进制兼容性问题吗？(Linux, GCC 4.1)

谢谢

我需要验证一些我有疑问的东西。如果共享库 (.dll) 是用 C 语言编写的，符合 C99 标准并在编译器下编译。说MinGw。然后根据我的经验，它是二进制兼容的，因此可以从任何其他编译器中使用。说 MS Visual Studio。我说以我的经验，因为我已经成功地尝试过不止一次。但我需要验证这是否是规则。

另外我想问一下是否确实如此，那么为什么完全用 C 语言编写的库，例如 openCV 不为每个不同的操作系统提供编译的二进制文件？我知道很明显的原因是设置所有编译时参数，但除此之外没有其他参数对吗？

编辑：我添加了一个附加问题，我认为这是对原始问题的逻辑扩展。这不就是创建一个封闭源代码库的方式吗？由于提供源的选项在那里消失了，因此提供二进制文件是唯一的选择。在这种情况下，为尽可能多的架构提供二进制文件是理想的结果，而 C 显然是在系统和编译器之间具有最佳可移植性的选择。对？

我在.NET 中实现了一个插件系统。基础库实现暴露给插件的基本类和接口，插件库链接基础库以使用暴露的类和接口。

我面临的问题是基础库的（简单）重新编译（有或没有修改）导致插件无法加载，并给出异常消息：

这个问题是通过同时编译基础库和插件库来解决的，但是在开发过程中这不是很舒服，因为我在这个阶段经常修改基础库。

如果有什么方法可以“放松”二进制匹配？

基础库程序集信息（引用如下）是否可能是问题的原因？

我忘了提到程序集是签名的。

使用以下例程加载程序集

我有一些编写 C 库的经验，但在编写此类库时，我从未阅读过任何描述良好实践的正式文档。我的问题主要涉及两个主题：

1. 如何保持二进制兼容性？（我听说过 pImpl 成语，d-pointer）
2. 如何设计保持向后兼容的接口？

从我的研究中可以看出，关于二进制兼容性的主要内容是，我可以使用 pImpl 习惯用法使库二进制兼容，但即使在使用 pImpl 时，更改结构/添加新数据成员等也会影响它的二进制兼容性。另外，有没有办法在不破坏二进制兼容性的情况下向库中添加新方法/函数？我假设添加这些东西会改变库的大小和布局，从而破坏兼容性。

有没有检查二进制兼容性的工具？

我已经阅读了这些文章。还有其他我可以阅读的文档吗？

http://en.wikipedia.org/wiki/Opaque_pointer

http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

此外，是否有文章在设计库接口的背景下描述了内存的所有权问题。一般约定是什么？谁拥有内存，多长时间，谁负责释放内存等？

我有一个可以编译为共享库（或 Windows 中的 DLL）的库。它有一个派生自另一个库中的另一个类的类。基类有一些虚拟方法，我的类覆盖了其中的一些。例如：

现在我发现其中一种虚拟方法对我的班级不太适用。目前它没有覆盖这个方法，所以我也想覆盖它来修复它的行为：

这会破坏与旧版本库的二进制兼容性吗？

据我了解，它与仅添加虚函数不同，因为 vtable 中虚方法的数量和顺序保持不变。唯一的区别是我的类的 vtable 中的特定条目现在将包含不同的值。这个对吗？

我也很确定当前使用我的库的应用程序都没有使用该方法，因为它完全损坏并且永远无法工作。所以我不担心破坏对基本方法实现的现有调用。我只是想确保我不会破坏其他任何东西。