Jeo*_*hum 3 c++ binary compatibility linkage
我不知道在 Windows 和 Linux 上保证 C++ 库的二进制兼容性的确切方法。但是我认为如果我使用 C 链接制作所有公开的 API，我想我可以轻松地保证在 Windows 和 Linux 上的这种兼容性。
就像下面这样：
extern "C" int SomeAPI();
其余的函数肯定会用 C++ 编写。只有对外公开的 API 才会有 C 链接。
并且公开的 API 必须是纯 C 函数——没有例外，没有使用 C++ 类型。
我是对还是错？我有什么误解吗？
我想即使使用 C 程序我也可以使用这个库。
我想要实现的兼容性是编译器向前兼容性和标准库向前兼容性。
我不能让它开源。我只需要关闭它。--> 我会努力让它开源。
我使用 boost 和 STL 来制作共享或静态 C++ 库。此外，我想知道兼容性不仅适用于编译，还适用于在 OS 中启动和运行。
我对吗？
对于二进制兼容性，同样重要的是应用程序二进制接口(ABI)。
顺便说一句，C++ 函数不仅可以返回一些结果，还可以抛出一些异常。您需要记录下来（即使您决定不抛出异常，这实际上很难实现，例如因为new可以抛出std::bad_alloc并且这可能发生在您软件的某些内部层中）。
请注意（尤其是在 Linux 上）C++ 标准库的 ABI 确实随着编译器的不同版本而改变。例如，std::string-s 或标准 C++容器的实现确实有所不同（在二进制级别以微妙的不兼容方式）。您可以静态链接 C++ 标准库（但这可能并不总是足够的，或者是脆弱的，例如，如果用户程序也需要它，因为他的代码是用 C++ 编写的）。
由于大多数 C++ 编译器和标准库在 Linux 上都是免费软件，因此您可以深入研究它们的源代码以了解所有细节。这应该需要您多年的努力，并且您需要对此进行预算。
所以这比你相信的更难。至少，记录用于构建您的东西的 C++ 编译器的版本，以及所涉及的 C++ 标准库的版本。
另一种方法（我推荐）可能是使您的东西成为免费软件或开源，并在github或其他地方发布源代码，并让您的用户编译您的源代码（使用他的C++ 编译器和 C++ 标准库）。
与各种 C++ 编译器和标准 C++ 库的二进制兼容性实际上很难实现，因为问题在于细节（如果你只发布一些二进制的东西）。您可能会发布使用各种编译器版本（例如，使用、等...）编译的多个二进制文件。 g++-5g++-6clang++-4.0
我不知道保证 C++ 库的二进制兼容性的确切方法
这样一个总的目标是不切实际的和过于雄心勃勃的。您最多可以发布几个二进制文件和文档，其中包含每个已编译的确切 C++ 编译器（以及版本和编译器选项）和 C++ 标准库。
我想要实现的兼容性是编译器向前兼容性和标准库向前兼容性。
这在一般情况下是不可能的。过去，各种 C++ 编译器确实破坏了 ABI 兼容性（这已被记录）。问题在于细节（因此，即使它在大部分时间看起来似乎都有效，但它通常可能有问题）。
我对吗？
不，你错了，而且野心太大。最多你可以发布一个二进制文件（可能你应该发布几个）并准确地说明它是如何构建的（什么 C++ 编译器和版本，什么编译标志，什么 C++ 标准库和版本，甚至什么 C 标准库和版本；如果你使用一些外部 C++ 或 C 库 - 如 Qt、Boost、Sqlite 等...... - 您还需要记录它们的版本）。C++ 的二进制兼容性是虚构的。
您可以并且可能应该使用（特别是在 Linux 上）包管理系统，例如为某些特定的 Linux 发行版（例如给定版本的 Debian 或 Ubuntu）发布一些.deb包。您将在二进制包中列出确切的依赖项。
请注意，维护多个二进制版本（和二进制包）是您应该预算的大量无聊工作。您可能会要求您的经理或客户允许打开您的库的源代码（而且这通常需要较少的工作）。例如，您的库可能是在GPLv3许可下发布的：开源程序可以自由使用它，但专有应用程序必须从您的公司购买一些其他许可。