如何查找不包含任何平台特定代码的Boost库

所有C++代码在某种程度上都是特定于平台的。一边是"纯标准C++代码"的理想概念，另一边是现实。大多数Boost库都是为了在用户端保持理想的状态而设计的，这意味着作为Boost的用户，你可以编写与平台无关的标准C++代码，而所有底层的特定于平台的代码都隐藏在这些Boost库的内部（为那些需要它们的人）。

但这个问题的核心是如何在现实世界中定义特定于平台的代码与标准C++代码。当然，你可以看看标准文件，说它之外的任何东西都是特定于平台的，但这只不过是一场学术讨论。

如果我们从这个场景开始：假设我们有一个平台，它只有C++编译器和C++标准库实现，并且没有其他操作系统或特定于操作系统的API来依赖标准库未涵盖的其他内容。好吧，在这一点上，你仍然需要问问自己：

• 这是什么编译器？什么版本
• 标准库的实现是否正确？没有Bug
• 这两个完全符合标准吗

据我所知，这基本上没有普遍的答案，也没有现实的保证。大多数奇异平台依赖于具有部分或不兼容标准库实现的奇异（或旧）编译器，有时会有自己强加的限制（例如，没有例外，没有RTTI等）。大量的"纯标准C++代码"永远不会在这些平台上编译。

然后，还有一个现实是，今天的大多数平台，即使是非常小的嵌入式系统，也有一个操作系统。它们中的绝大多数在某种程度上都符合POSIX（除了Windows，但Windows无论如何都不支持任何奇异的平台）。因此，实际上，依赖POSIX函数的特定于平台的代码并没有那么糟糕，因为在大多数情况下，大多数奇异的平台可能都有它们。

我想我在这里真正得到的是，你脑海中关于"纯C++"与平台特定代码的纯粹分界线实际上只是一条想象的分界线。每个平台（编译器+std-lib+OS+ext-libs）都位于对标准语言功能、标准库功能、OS API函数等的连续支持级别上。因此，所有C++代码都是特定于平台的。

唯一真正的问题是它能撒下多大的网。例如，大多数Boost库（除了最近的"脆弱"库）通常支持编译器，支持程度可以降到C++98的合理水平，许多甚至试图支持90年代早期的编译器和std-lib。

要知道Boost的一部分库是否对您想要的应用程序或平台有足够广泛的支持，您必须定义这种支持的边界。仅仅说"纯C++"是不够的，它在现实世界中毫无意义。您不能说您将在使用Boost.Thread作为具有特定平台代码的库的示例之后立即使用C++11编译器。许多C++11实现对std::thread的支持非常脆弱，但其他实现做得更好，这个问题与使用Boost.Thread一样是"特定于平台的"问题。

确保平台支持范围的唯一真正方法是实际设置的机器（例如，虚拟机、模拟器或真实硬件），这些机器将提供具有代表性的最坏情况。你必须根据对客户可能使用的东西的现实评估来选择那些最坏的机器，并且你必须保持最新的评估。您可以为您的特定项目创建一个使用特定（Boost）库的回归测试套件，并在所有最坏的测试环境中测试该套件。任何没有通过测试的，都没有通过测试，就这么简单。是的，你可能会发现，某些Boost库在某些新的奇异平台下无法工作，如果发生这种情况，你需要让Boost开发团队添加代码来支持它，或者你必须重新编写代码来绕过它，但这就是软件维护的全部内容，这是你必须预料的成本，而这些问题不仅来自Boost，但来自操作系统和编译器供应商！至少，使用Boost，您可以自己修复代码并将其贡献给Boost，而操作系统或编译器供应商不能总是这样做。

我们也进行了"Boost or not"的讨论。我们决定不使用它。

• 我们有一些不典型的硬件平台与一个源代码一起使用。特别是在AVR上运行boost是不可能的，因为boost在很多事情上都需要RTTI和异常，但这些都不可用
• boost的某些部分使用编译器特定的"黑客"来获取有关类结构的信息
• 我们尝试拆分包，但相互依赖性相当高（至少在3或4年前）

与此同时，C++11正在进行中，GCC开始越来越多地支持它。随着使用boost的众多原因逐渐消失（哪些boost功能与C++11重叠？）。我们从头开始实现了其余的需求（由于C++11中的可变模板和其他TMP功能，我们的工作量相对较低）。

在经历了一段陡峭的学习曲线后，我们在没有外部图书馆的情况下拥有了所需的一切。

与此同时，我们对Boost的未来进行了思考。我们预计新标准化的C++11功能将从boost中删除。我不知道Boost目前的路线图，但当时我们的不确定性使我们投票反对Boost。

这不是你问题的真正答案，但它可能会帮助你决定是否使用Boost。（很抱歉，它太大了，无法发表评论）