C ++跨平台代码

2018-06-19 08:51:50

我们将在我们的小团队中开始一个新项目：

这是一个将被我们其他项目（Linux和Windows）使用的库。

它不是依赖于逻辑平台的（它不使用任何系统调用或类似的东西）。

它必须在各种平台上进行编译（至少包括Windows和Linux）。

不幸的是，我们的开发者中没有一个在Windows以外的任何平台上编写过任何代码！因此，我必须给他们一个“这样的代码”或“不是这样的代码”列表，所以代码将保持跨平台。

任何指导？

增加可移植性的一种方法是在两个平台上使用相同的编译器GCC。如果您还使用相同的编译器版本，则可能会避免大部分（如果不是全部）C ++语言和标准库不兼容。您也可以使用相同的构建工具，如GNU make，这意味着构建过程在两个平台上都是相同的。

至于平台不兼容性 - 请检查他们的代码是否包含如下内容：

#include <windows.h>
#include <unistd.h>
#include <sys/almost_anything.h>

除非这是通过条件编译完成的。

确保您在所有平台上都有自动构建过程，并编写单元和自动功能测试。如果可能的话，运行夜间自动构建和测试。当你编写跨平台的库时，这更重要。

我会做相反的其他答案之一（并非我认为这是错误的，只是一种不同的方法），如果你可以选择你的平台使他们尽可能不同。例如，在unix上创建一个32位MCVC和另一个64位gcc。如果你可以进行自动化测试和构建，那么这将很快显示可移植性问题。

如果可能的话，一些开发人员在一个平台上工作，另一些人在另一个平台上工作，而不是在一个平台上完成代码，然后将其“移植”到另一个平台上。这样他们就会很快学会在他们的同事过来抱怨他们弄坏了什么时不该做什么。

技术上要注意的是

不要认为整数是32位

不要认为char的签名或未签名

不要假定字符是ASCII

不要假设数据字节顺序或对齐

最小化指针算术。当你做出失败的假设时，你只会犯错。

记住文件和目录名在不同平台上的工作方式不同。如果你只需要移植到windows和unix，你可能会对它感到厌倦，但是一旦你移植到了两个平台，那么下一个端口可能是z系列或VMS，这些工作的工作方式完全不同。

最重要的是：在所有支持的平台上始终运行自动构建和测试，以便立即获取大多数不可移植（或错误）的代码。

语言本身，标准库和Boost应该可以移植到任何广泛使用的平台（当然是现代版本的Linux / GCC和Windows / MSVC）。怀疑以.h结尾的任何系统头文件，并在决定使用它们之前检查其他库的可移植性。

保持一份所遇到的所有不兼容的文件，希望你只会犯一次错误。

链接地址: http://www.djcxy.com/p/54545.html