4

我的问题与此类似，但也涉及静态库：

我们有一个跨平台的 C++ 头库，它可以在 Windows/Linux/Os X 下很好地构建，适用于多个编译器，包括 32 位和 64 位。当用户安装了 zlib 或 libbz2 时，构建系统通过#ifdefs.

为了让我们的用户更容易使用，我们希望以二进制格式或作为源代码发布用于 Windows 的 zlib 和 libbz2 等库，只需点击几下即可安装。（在 Linux 和 Mac Os X 上，库可以简单地安装，因为系统包实际上在大多数标准安装中都可用，据我所知）。

最终的解决方案应该使用户能够在 32 位和 64 位 Windows 上使用 Visual C/C++ 编译器 2005、2008 和 2010 以及 MinGW，以便轻松链接到 zlib 和 libbz2。我们目前只关心 C 库和可预见的未来。

这些库应该单独构建，我们不想将构建它们集成到我们的构建系统中。

据我所知，这里至少有两个自由度：

  • 是否使用静态库或 DLL。
  • 是发布二进制库还是让用户构建自己的库。

另一点是用户应该能够将库链接到他们程序的调试和优化版本。我不是 Windows 编程方面的专家，但据我在 Internet 上和其他工作中的开发人员那里了解到，Windows 上的调试和发布版本之间存在这种（不寻常的？）区别。显然，您不能将调试程序与发布库链接，反之亦然。它是否正确？

好的，为了清楚起见，让我再次总结一下：（1）为我们的 C++ 编译器提供依赖 C 库的最佳方式是什么？ (2) 如果我们以后还想发布 C++ 库，让用户使用每个编译器从源代码构建是唯一可行的方法，对吗？

4

2 回答 2

2

为我们的 C++ 编译器提供依赖 C 库的最佳方式是什么？

没有完美的解决方案，但如果为您认为他们将使用的编译器（至少对于 Visual Studio）提供 DLL 以及相应的头文件和导入库，您的用户会更轻松。请注意，大多数编译器都提供了从 DLL 二进制文件创建导入库的工具。

您还可以以源代码形式发布库，并提供在不同编译器上构建它们的脚本。

如果我们以后还想发布 C++ 库，让用户使用每个编译器从源代码构建是唯一可行的方法，对吧？

一般来说，使用导出 C++ 类和方法的 DLL 是一个非常糟糕的主意，因为它们是以编译器相关的方式导出的，实际上迫使您为每个受支持的编译器提供不同的 DLL。在使用 C++ 库时，我采取了以下措施：

  1. 构建静态库，而不是 DLL。
  2. 将 C++ 库的构建合并到我的项目的构建中（例如，作为依赖项目），确保所有内容都由相同的编译器构建。

如果我理解这一点，您的用户就是构建应用程序的用户，您只是为他们提供了您的标头库。所以在我看来，在这种情况下，您需要记录他们如何将 C++ 库添加到他们的应用程序中，也许最好的方法是提供一个完全工作的示例应用程序，该应用程序还可以从源代码构建 C++ 库，至少针对 Visual Studio 和您知道您的用户可能使用的任何其他编译器。

祝你好运。

于 2011-10-29T17:55:42.243 回答
1

为了获得最大的二进制兼容性，最好的方法是在 Windows 平台上将您的 c/c++ 库作为 COM 公开

COM 对象可以从 C、C++ 和 .NET 语言中使用

于 2011-10-29T17:23:22.227 回答