程序可移植性

Question

如何确保我的程序完全可移植？

Answer 1

在所有目标平台上持续集成。

Answer 2

1。测试

这是做必要的必要但不充分的条件。要测试可移植性，您需要多个平台和编译器。

2。写入标准，而不是开发平台。

这意味着，只有在标准表明您可以这样做的情况下才能做某事。如果标准表明你可以期待它，那么只期望一个特定的结果。仅在标准表明存在时才使用库或API。该标准可在此处（以及其他地方）：

http://openassist.googlecode.com/files/C%2B%2B%20Standard%20-%20ANSI%20ISO%20IEC%2014882%202003.pdf

如果您认为：

，这会有所帮助

• CHAR_BIT等于9.
• sizeof（int）等于5，int是37位类型。或16位类型。
• 基本字符集是EBCDIC。
• 这个时代始于1721年。
• time_t是double

等等。我并不是说，编写依赖于那些事情的代码是真的，我的意思是编写代码，如果它们是可行的，并且也将用于理智的实现。

3。使用您可以找到的最严格和最迂腐的编译器选项

这是给自己一个合理机会实现（1）的唯一实用方法。

4。理解“真正的编译器”无法正确或完全实现标准，并对此事做出一些让步。

从理论上讲，使用export的C ++程序没有任何不可移植性。如果它在所有其他方面都是一个非常好的C ++程序，那么它将适用于任何符合标准的C ++编译器。但几乎没有人使用符合标准的C ++编译器，所以你需要坚持使用事实上的 C ++公共子集。

5。了解C ++标准提供了相当受限的编程环境

某些东西在标准C ++中不可移植，例如在屏幕上绘制图形，因为标准C ++没有图形或GUI API。因此，没有用C ++编写的“完全可移植”的GUI程序。因此，根据您的计划应该做什么，您可能需要也可能不需要修改目标。

如果您的程序需要完全不能在标准C ++中完成的东西，那么您可以通过将该行为封装在您认为应该在您关心的所有平台上实现的接口中来使程序更容易移植。然后设置为每个实现它。但是，这并不会产生“完全可移植”的程序，因为对我来说，这意味着一个程序可以在任何符合要求的C ++实现上编译和运行。一个可以通过C ++编译器移植到大多数平台的程序，假设它们有一个屏幕和一个鼠标，并且有一些定制的编程工作，可能不是一回事。

当然，所有这些都可以走得太远。您可能实际上想要假设CHAR_BIT是8（否则读取文件是疯狂的），甚至可能依赖于像Qt这样的GUI框架。但你确实说过，“完全可移植”，编写便携式程序需要做的主要事情之一就是找出你愿意“完全”妥协的程度。

6。断言你的假设

在编译时，如果可以，或者运行时，请确保如果您的程序要求int至少为32位（或其他），那么当它不是时会失败。好的，如此全面的测试覆盖会遇到你的算法无声地溢出并给出错误答案的情况，但很难编写真正全面的测试，无论如何测试可能会产生与代码相同的非可移植错误，或者一些可怜的傻逼者已下载您的代码可能无法正常运行它们。

使用库时，您实际上是在自动执行此操作。您将#include一些标题，如果该库不可用，将立即失败。至少，你希望它会 - 可以想象，其他一些实现可能有一个同名的标题，它做了一些根本或微妙的不同。激进差异通常会导致编译失败，因为您可以测试preprocessor symbols to identify implementations的细微差别。

Answer 3

你的问题：

  

如何确保我的程序完全可移植？

无法满意地回答。您不能，在任何实际应用中，确保它是可移植的。您只能通过在目标平台上对应用程序进行准确测试来证明您的期望，正如Lou Franco已在此处提出的那样。

在不同平台或环境下并行开发和测试的过程中，我们每个人都找到了他的技巧，并探讨了他的一些陷阱。您在一个评论中说过，您在Windows系统上工作。这可以。尝试让您的程序使用Visual Studio编译器（和环境）。然后，安装CygWin with the GCC 4.x编译器套件。安装Netbeans IDE & C++ Environment并基于相同的源创建项目。 Netbeans将使用Cygwin GCC 4.x.如果您编译的程序适用于两个工具链，那么您可能掌握了大约90％的实际可移植性障碍。

此致

RBO

Answer 4

避免使用特定于平台的库。

Answer 5

• 使其符合标准。至少是您打算部署应用程序的所有平台上的供应商实现的标准的通用子集。

• 从平台无关的部分中分解出特定于平台的部分。通常，最低层或两层应该处理平台。

• 及时了解：

  • 平台/ OS API
  • 工具链
  • 语言功能

• 测试，部署。冲洗并重复。

Answer 6

在开发期间，在每个平台上对其进行单元测试

Answer 7

在最严格的编译环境中开发。使用C ++中最小的一组功能。将依赖于平台的代码部分拆分为单独的文件。为每个平台开发配置（make）环境，作为软件包的一部分。

Answer 8

避免使用特定于平台的库。如果您只能使用STL和BOOST实现所需的功能，请继续。

Answer 9

确保仅使用实际存在于所有目标平台上的库将是一个良好的开端。

Answer 10

这是不可能的。当我编写具有奇怪C编译器的操作系统时会发生什么？

那说，要便携，你需要：

• 避免使用Win32
• 避免POSIX（这很烦人......你可能只想使用Cygwin来提供Windows支持）
• 避免使用任何特定于平台的库。这通常会将图形限制为wxWindows，GTK和QT。
• TEST。确保它有效。
• 不要假设任何事情。 Windows很奇怪并使用\ r \ n，所以要小心。
• 我认为Windows上的Visual C ++会为您提供有关“不安全的c函数”的警告，并要求您使用“安全的”，这不是标准的。不要因为微软垄断你的程序而感到沮丧。

有些事情会有所帮助：

• Autoconf将允许任何体面的系统（即包含shell的系统）检测常见的可移植性问题并设置正确的标头
• Cmake也可以这样做，但只能在Cmake本身可用的平台上

Answer 11

了解您打算发布的平台。如果某些平台惯例与标准相矛盾，则忽略该标准。我很认真。例如，如果您使用带有std::ifstream参数的标准char*构造函数，则无法在Windows上打开任何带有Unicode文件名的文件 - 您必须在那里使用非标准wchar_t*重载。由于无法打开平台上允许和合法的文件而丢失的功能严重超过了仅使用标准所知的可移植性;最后，重要的是功能，而不是对特定标准的遵守。

Answer 12

这不是对问题的直接回答，而是根据其他答案的答案。

您需要平衡绝对可移植性的要求与平台用户的期望 - 对于Windows，OS X，KDE和Gnome有不同的基本HCI / HIG指南，并且任何便携式GUI工具包都不会自动生成正确的结果在每个（有些允许你应用不同的布局，这是一个开始）。

inbetween方法是拥有一个具有多个本机GUI的纯可移植核心。

没有必要（虽然忽略了约定，但仍有很多软件可以成功），但需要考虑这种权衡 - 特别是如果存在强大的原生应用程序。