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

时间:2014-09-30 15:55:20

标签: c++ boost

对于我们当前的项目,我们正在考虑使用Boost框架。

然而,该项目应该是真正的跨平台,并可能被运送到一些异国情调的平台。因此,我们希望使用 Boost包(库),它们不包含任何特定于平台的代码:纯C ++,就是这样。

Boost的想法是只有标头包(库)。

可以假设这些包(库)没有特定于平台的代码吗? 如果没有,是否有办法识别这类Boost包?

2 个答案:

答案 0 :(得分:1)

所有C ++代码在某种程度上都是特定于平台的。一方面,有一个理想的纯标准C ++代码概念"另一方面,有现实。大多数Boost库旨在维护用户端的理想情况,这意味着您作为Boost的用户可以编写与平台无关的标准C ++代码,而所有底层平台特定代码都隐藏在那些Boost库的内容(对于那些需要它们的人)。

但是这个问题的核心是如何在现实世界中定义特定于平台的代码与标准C ++代码的问题。当然,您可以查看标准文档,并说除了它之外的任何内容都是特定于平台的,但这只不过是一次学术讨论。

如果我们从这个场景开始:假设我们有一个只有C ++编译器和C ++标准库实现的平台,并且没有其他操作系统或特定于操作系统的API可以依赖于其他未涵盖的内容由标准库。那么,那时你还是要问自己:

  • 这是什么编译器?什么版本?
  • 标准库实现是否正确?无缺陷?
  • 这两个完全符合标准吗?

据我所知,对此基本上没有普遍的答案,也没有现实的保证。大多数异国情调的平台依赖于具有部分或不符合标准库实现的外来(或旧)编译器,并且有时具有自我施加的限制(例如,没有例外,没有RTTI等)。大量的纯标准C ++代码"永远不会在这些平台上编译。

然后,现在大多数平台都存在这样的现实,即使是非常小的嵌入式系统也有操作系统。其中绝大多数都符合某种程度的POSIX(Windows除外,但Windows并不支持任何异国情调的平台)。因此,实际上,依赖于POSIX功能的特定于平台的代码实际上并不是那么糟糕,因为大多数奇怪的平台很可能拥有它们。

我想我在这里真正得到的是这个纯粹的分界线,你在脑海里想到了纯粹的C ++"与平台特定的代码实际上只是一个虚构的代码。每个平台(编译器+ std-lib + OS + ext-libs)都位于对标准语言功能,标准库功能,OS API函数等的连续支持级别。通过该措施,所有C ++代码都是特定于平台的

唯一真正的问题是它投射的网络有多宽。例如,大多数Boost库(除了最近的"脆弱的"之外)通常支持编译器降低到合理的C ++ 98支持级别,并且许多甚至尝试支持早在90年代早期的编译器和std -libs。

要了解某个库(Boost与否的一部分)是否对您的预期应用程序或平台有足够的支持,您可以定义该支持的边界。只是说"纯C ++"是不够的,它在现实世界中没有任何意义。在您将Boost.Thread作为具有特定于平台的代码的库的示例之后,您不能说您将使用C ++ 11编译器。许多C ++ 11实现对std::thread提供了非常脆弱的支持,但是其他实现更好,而且这个问题与特定于平台的#34;相同。问题就像使用Boost.Thread一样。

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

答案 1 :(得分:1)

我们有"是否提升"讨论也是。我们决定不使用它。

  • 我们有一些非典型的硬件平台可以提供一个源代码。特别是在AVR上运行增强是根本不可能的,因为RTTI和异常(Boost需要很多东西)是不可用的。
  • 有些部分的使用编译器特定的" hacks"例如获取有关类结构的信息。
  • 我们尝试拆分包,但是依赖性相当高(至少3或4年前)。

与此同时,C ++ 11正在进行中,GCC开始支持越来越多。有很多理由可以使用boost faded(Which Boost features overlap with C++11?)。我们从头开始实现其余的需求(由于C ++ 11中的可变参数模板和其他TMP功能,所以需要相对较少的努力)。

经过陡峭的学习曲线,我们拥有了所有我们所需要的,无需外部库。

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


这不是您问题的真实答案,但它可以帮助您决定是否使用Boost。 (对不起,评论很重要)