在跨平台库上工作答案

【问题标题】：Working on a cross platform library在跨平台库上工作
【发布时间】：2025-11-26 00:45:01
【问题描述】：

用 C++ 编写跨平台库的最佳实践是什么？

我的开发环境是 Linux 上的 Eclipse CDT，但我的库应该也可以在 Windows 上进行本地编译（例如来自 Visual C++）。

谢谢。

【问题讨论】：

请问这个库是干什么用的？几乎所有东西都可能已经有了跨平台库。

标签： c++ windows linux eclipse compilation

【解决方案1】：

在某种程度上，这将取决于您的库究竟要完成什么。

如果您正在开发一个 GUI 应用程序，例如，您会希望专注于使用一个经过良好测试的跨平台框架，例如wxWidgets。

如果您的库主要依赖于文件 IO，您需要确保使用现有的经过良好测试的跨平台文件系统抽象库，例如 Boost Filesystem。

如果您的库不是上述任何一种（即没有现有的经过良好测试的跨平台框架供您使用），那么最好的办法是确保您遵守标准 C++尽可能（例如，这意味着不要#include <linux.h> 或<windows.h>）。如果这是不可能的（即您的库从麦克风读取原始声音数据），您需要确保给定平台的实现细节被充分抽象出来，以便最大限度地减少工作参与将您的库移植到另一个平台。

【讨论】：

是的。此外，[gtk.org/download-windows.html glib] 对所有最低级别的 C 类东西（例如 malloc 和 strcmp）都有抽象。
作为附录，我要补充一点，将特定于平台的代码（如果有的话）分离到自己的模块中通常很有用。您的其余代码与平台无关，可以通过调用接口函数来执行特定于平台的任务。这样一来，移植你的库就可以（在很大程度上）简化到移植单个模块的过程。
我唯一要指出的是，您不一定要强制需要另一个库。人们可能希望它独立工作（STL 是一个例外，因为它是 C++ 标准的一部分）。
@Mark 多平台库是如何制作的？他们怎么能是跨平台的，他们是否使用每个平台API（例如boost文件系统是否使用每个系统API来管理文件，因为我看不到其他方法，因为c ++语言甚至不理解目录是什么？ ) ?

【解决方案2】：

据我所知，您可以做以下几件事：

您可以将平台特定的代码划分为不同的命名空间。
您可以使用PIMPL idiom 隐藏平台特定代码。
您可以使用宏知道要编译什么代码（在这种情况下，代码将是特定于平台的）。查看此link 了解更多信息。
在多个环境中测试您的库。
根据您的操作，使用 Boost 等库可能会更好，因为它不是特定于平台的。缺点（或可能是好的一面）是您将强制使用您包含的库。

【讨论】：

【解决方案3】：

从我的实践经验中提几点建议：

1) 确保在您的目标平台上定期编译源代码。不要等到最后。这有助于及早指出错误。使用持续构建系统——它让生活变得更轻松。

2) 切勿使用特定于平台的标头。甚至不用于编写本机代码 - 就您所知，windows 标头中的某些内容可能期望某些字符串在 XP 中为 ABC，但在 Win7 中更改为 ABC.12。

3) 使用来自 STL 和 BOOST 的想法，然后在它们之上构建。永远不要认为这些是解决问题的灵丹妙药——STL 很容易随您的代码一起发布，但 BOOST 则不然。

4) 不要使用编译器特定的结构，如 __STDCALL。这是在自讨苦吃。

5) 在 g++ 和 cl 中使用类似的编译器选项编译相同的代码时，可能会导致不同的行为。请准备一份非常方便的编译器手册。

【讨论】：

【解决方案4】：

每当我从事这样的工作时，我都会尝试在我希望得到支持的不同环境中构建它。同样，如果你正在制作一个网页，并且想确保它在 IE、Firefox 和 Chrome 中工作，你会在所有这三种浏览器中测试它。在您想要支持的不同环境中对其进行测试，您就会知道可以放心地说它适用于哪些系统。

【讨论】：

Web 开发和应用程序开发是完全不同的。 ;)
不是我写的内容。您需要在您打算使用的每个平台上测试您的代码。
我同意你的看法。唯一的问题是 Alon 可能对 Web 开发一无所知。
其实我是web开发背景的:)

【解决方案5】：

上述问题有点抽象。但你可以考虑 QT

【讨论】：

【解决方案6】：

实际上就像“不使用任何特定于平台的东西”一样简单。如今，大量免费可用的工具使得用 C++ 编写跨平台代码变得轻而易举。对于那些您确实需要使用特定于平台的 API 的罕见但偶尔的情况，请务必通过 #defines 将它们分开，或者在我看来更好的是，为每个平台使用不同的 .cpp 文件。

跨平台库有很多替代方案，但我个人的偏好是：

界面：Qt
OS 抽象（尽管 Qt 自己在这方面做得很好）：Boost
跨平台 Makefile：CMake

最后一个，CMake，在过去几年中对我提供了巨大的帮助，让我在 Windows 和 Linux 上进行双重开发时保持构建环境的健全。它的学习曲线相当陡峭，但一旦启动并运行，它就会非常好用。

【讨论】：

-1：您可以使用特定于平台的代码。只需要采取必要的措施，这样代码就不会针对特定环境进行编译。
您建议的第一件事是不要使用特定于平台的代码。更不用说您建议在不一定是最佳行动方案时使用现有库。当然，您是说可以使用特定于平台的代码。问题是您定义这是一个罕见但偶然的情况，而不知道 Alon 正在做什么类型的库。
@Alerty 你是对的。我只是那些认为一般问题值得一般答案的疯子之一。不过不用担心，通过折纸和锡纸的神奇组合，我的读心设备很快就准备好了:)
@Rakis 多平台库是如何制作的？他们怎么能是跨平台的，他们是否使用每个平台API（例如boost文件系统是否使用每个系统API来管理文件，因为我看不到其他方法，因为c ++语言甚至不理解目录是什么？ ) ?
@Mekacher 跨平台库在必要时使用特定于平台的 API，但它们将它们抽象化，以便将库使用者与特定于平台的差异隔离开来。通常，这会导致最小公分母问题，即无法公开功能，而在每个库支持的平台上都不存在支持。您指出的目录问题就是一个很好的例子，因为并非所有系统都对构成“目录”的内容有类似的定义，尽管所有平台都有一个命名的、连续的字节序列（又名“文件”）的概念。尽管即便如此，具体情况也有所不同

【解决方案7】：

您的意思是除了在目标平台上进行持续集成和测试之外？或者除了使用设计来抽象出实现细节？

不，什么都想不起来。

【讨论】：