确保跨平台兼容性(C++)的技术？

Question

我正在完成我最早的一个C++项目，这个项目(根据框架)应该是跨平台的。我在Windows和Visual中完全开发了这个项目，认为由于库都是跨平台的，那么“稍后”进行OSX构建就很简单了。结果不是这样的，而是"Windows代码“不能正常运行，并且有一些编译错误需要修复。

有哪些技术可以预先确保代码与所有平台兼容？同时开发所有平台，从而在添加新功能时，同时针对每个平台测试代码，而不是一个接一个地开发不同的平台版本？(*)

具体而言，这并不取决于工具，而是帮助跨平台兼容性的“开发过程”，不管使用的是什么工具。就像上面的(*)。

具体来说，我正在开发一个带有WDL-OL (https://github.com/olilarkin/wdl-ol)和一些跨平台DSP库的VST插件。WDL-OL项目同时设置了VS和Xcode项目，但我想问题可能来自于库，然后是编译器的差异。

Answer 1

创建可移植代码可能非常具有挑战性。

首先，一些明显的与语言有关的建议：

• 使用标准C++，小心避免任何未定义行为
• 主要依赖标准库(以及可移植库(如助推) )
• 始终包括所有预期的标题。不要假设您不需要一个标头，因为它包含在另一个头(i.e.on，一个特定的实现!)：这会导致编译错误
• 避免由编译器支持但不受C++标准(例如匿名结构或变长阵列)保证的构造:可能导致编译错误。
• 使用编译器选项帮助您强制执行遵从性(禁用编译器特定的扩展，最大限度地提高返回的警告消息的级别)
• 请记住，代码工作是不够的:有许多与实现相关的可移植性缺陷:数据类型的大小(甚至是基本的)、可以是默认情况下签名或未签名的字符、关于痴呆症的假设、使用副作用时表达式中的计算顺序等等。

然后给出几个设计建议：

• 更倾向于标准库替代等效的操作系统功能。
• 尽可能隔离操作系统依赖项的使用(例如，在条件编译控制的包装函数中)

最后，微妙之处：

• 字符编码:在许多系统上，您可以依赖utf8。但是对于Windows来说，它更微妙，因为系统要么期望ansi，要么期望utf-16。当然，您可以依赖类型胡枝子(如TCHAR，但这可能是与标准库结合使用的挑战(例如，根据使用char还是wchar_t，要使用cout与wcout )。
• 如果对于GUI/图形/高级I/O，您无法找到适合您的期望/需求的可移植库，则设计总体架构以隔离特定于OS的组件。包装器在这里可能是不够的，因为涉及到许多不同的交互和概念。
• 利用一些有趣的设计模式，例如抽象工厂 (用于设计特定于OS的UI等相关对象的系列)或调解员 (理想地实现相关对象之间的协作)，并与条件编译一起使用。

但这些只是建议。在这个领域，你无法获得确定性。

Answer 2

除了构建、运行代码并在平台上进行测试之外，没有什么可以保证代码与平台兼容。因此，所有正常人的方法是在他们设计的每个平台上构建、运行和测试他们的应用程序，这些应用程序需要构建、运行和测试。

持续集成( Continuous，CI)可以减轻较小项目的负担，因为您可以为某些平台(主要是Linux)获得廉价或免费的构建代理，在Windows上进行开发，并在出现问题时直接返回Linux。

OSX是相当棘手的，尽管。

Answer 3

这取决于您提到的“一些编译错误”。如果不知道它们是什么，就不可能是具体的。

我有Windows / Linux / iOS / Android / Mac的跨平台代码。每个新平台第一次添加时都会带来一些额外的错误和警告。您将很快了解哪些构造会带来问题。要么避免它们，要么用#ifdefs将差异抽象成一个标题。尽量不要在代码本身中在不同平台之间使用#ifdef。

一个例子是：

void myfunction(MyClass &);
myfunction(MyClass());

创建MyClass的临时实例，在myfunction返回后删除该实例。对于我的一些C++编译器，这个实例是读/写的(而且它是临时的，很快就会被销毁，这一点编译器并不担心)。对于其他情况，必须重新定义myfunction以获取const MyClass &，否则编译器会发出抱怨。不管C++标准说什么，哪个编译器是对的，哪个是错的。在遇到错误几次之后，我知道(a)要么声明一个类型为MyClass的临时变量并将其传递给myfunction，要么(b)在myfunction中声明引用const，然后在这里和那里使用mutable来解压缩。

底线:积累经验并制定自己的编码标准。