使用不可移植代码的理由答案

【问题标题】：Justification for using non-portable code使用不可移植代码的理由
【发布时间】：2010-11-05 08:45:02
【问题描述】：

如果有人在优化代码、实现的清晰度、效率和可移植性方面证明他们的设计权衡是合理的，该如何选择？

与此问题相关的示例可能是大文件处理，其中“大文件”是“相当几 GB”的问题，可以使用随机访问方法进行简化。

读取和修改此文件的方法可能是：

无论如何都要使用流，并寻找所需的位置 - 可移植，但可能很慢，并且不清楚 - 这几乎适用于所有操作系统。
将文件的相关部分映射为一个大块。例如，为每个块映射一个 50MB 的文件块进行处理 - 这适用于许多操作系统，具体取决于为该系统实现 mmap 的细微之处。
只需 mmap 整个文件 - 这需要 64 位操作系统，是实现此功能的最有效和最清晰的方法，但不适用于 32 位操作系统。

【问题讨论】：

mmap 非常便携。只要虚拟内存可用，它就可以在每个主要操作系统（包括嵌入式操作系统）上以某种形式使用。在虚拟内存不可用的系统上，mmap 调用可能可用，但在性能方面通常不是很好，并且没有完全相同的行为，包括脏页。
令牌：多 GB 文件的虚拟内存在 32 位系统上肯定不可用。
您不必一次映射整个文件。正如 OP 所说，您可以一次映射一块。

标签： portability

【解决方案1】：

没有约束，这个问题在理性上是无法理性回答的。

你问“什么是最好的颜色”，却没有告诉我们你是在画房子、汽车还是图片。

约束至少包括

选择的语言
目标平台（多 CPU 工业级服务器还是 iPhone？）
针对速度与内存进行优化
成本（谁出资，是否存在交付限制？）

任何软件都不可能具有“终极”可移植性。

WideFinder 项目是使用多种方法处理此类问题的示例，但对所需的特定输入/输出和“最佳”度量都有严格的限制。

【讨论】：

我更关心“最佳实践”——例如，即使只为 Linux 编写，使用可移植 POSIX 库也被认为是最佳实践，而不是使用特定于操作系统的函数，如果两者碰巧等价。

【解决方案2】：

不确定您要问什么，但设计过程的一部分是分析对可移植性和性能（以及其他因素）的要求。

如果您知道永远不需要移植代码，并且绝对需要最佳性能，那么您可以相应地调整您的实现。仅仅为了便携而便携是没有意义的。

另请注意，如果您既想要性能又想要可移植性，那么没有什么能阻止您为每个平台提供实现。当然，这会增加您的成本，所以实际上，这取决于您优先考虑您的需求。

【讨论】：

“仅仅为了它自己而可移植是没有意义的” - 一个有趣的概念，但即使您推迟实际测试，将您的应用程序设计为可移植也不被认为是最佳实践真正需要时的备用操作系统？
可移植性是有成本的，而开发人员是有限的资源。 “敏捷”开发说不要做超过你需要的事情；当然，我们明智的做法是不要太从字面上理解。但找到平衡仍然取决于项目和资源。例如，我可能会开发一个仅限 Win32 的应用程序，知道它“可能”与 WINE 一起运行，或者假设它可以在 VMware 下的 OS/X 上运行。所以从这个意义上说，我正在将可移植性推给其他人。
@Arafangion - 不，如果你不需要它，那么做任何事情都不是最佳做法。
@Justicle：最好让程序可移植，这样可以让尽可能多的人使用该程序。如果您将代码设计为永远不可移植，那么在为任何操作系统的下一版本升级程序时，祝您好运。 ;)
@Partial - 当然！最好还是让您的程序尽可能快地运行，使用尽可能少的资源，尽可能少的错误，并在尽可能短的时间内开发。你明白我的意思吗？ :-)

【解决方案3】：

这实际上取决于项目的驱动程序。如果你在做内部企业开发，那么做最简单的事情，可以在你的目标硬件上工作。根据需要对性能要求进行 Mod。

如果您在第一天就知道需要支持不同的硬件平台，那么您显然需要选择可移植的实现，或者使用多种方法。

【讨论】：

你会如何选择为单一操作系统编码，即让你的程序严重依赖 win32，或者设计你的应用程序，以便只有最少量的代码依赖于 win32，以防万一你可能想在 Mac OS X 或 Linux 上使用它？即使我从不打算更改任何组件，我至少会尝试使用 MVC 架构（或类似架构）。
@Arafangion：您可以将您的代码设计为将来可移植，而无需在一开始就实现该可移植性。 OOP 可以提供很多帮助，也可以使用接口。 Pimpl 成语确实是实现这一目标的好方法。

【解决方案4】：

基本上，您需要在编码之前先思考。每个项目都是独一无二的，对需求的分析可以帮助决定什么是最重要的。对于任何项目来说，最佳解决方案取决于几件事...

首先，这个项目是否需要或最终是多平台的？根据您的选择，选择正确的编程语言应该更容易。然后你也可以在你的项目中使用不止一种语言，这是完全正常的。可移植性并不一定意味着较低的性能。这意味着要实现目标需要付出更多的努力，因为您需要高质量的代码。此外，每种编程语言都有自己的哲学。了解它们是什么。有一件事是肯定的，某些问题经常反复出现。这就是为什么了解不同的设计模式有时会有所作为，但有些语言有自己的习语，在选择语言时可能非常相关。需要考虑的另一件事是您可以为您的项目采用的不同方法。多线程、套接字、客户端/服务器系统和许多其他技术都可供您使用。选择正确的技术有助于使项目变得更好。

了解需求和当今可用的不同解决方案将有助于决定何时选择不同的权衡。

【讨论】：

【解决方案5】：

为了可移植性而进行的可移植性从一开始就一直是 Java 的营销策略，并且按照惯例对于 C 来说是生活中的一个事实，我相信大多数遵守它的人都会这么说。

然而，绝对的可移植性仅适用于最琐碎到最多具有中等复杂性的应用程序——任何具有高复杂性的应用程序都需要专门的调整。

【讨论】：