加强宣传 - 需要帮助答案

【问题标题】：Boost advocacy - help needed加强宣传 - 需要帮助
【发布时间】：2009-09-17 06:36:24
【问题描述】：

可能重复
Is there a reason to not use Boost?
What are the advantages of using the C++ BOOST libraries?

好的，高级问题是“请向我提供您认为最有效的论据，说明为什么整个 Boost 或它的某些特定部分应该在我们公司的系统上编译并在软件工程标准中得到认可”。

我需要的详细信息：

很乐意接受正面的论点（为什么要安装），以及对我可能听到的可能的反论点提出的反驳（请参阅下面的问题上下文）。
应针对技术软件工程团队成员和/或非常技术高级管理人员提出论点 - 换句话说，对于后者，论点的细节可能/应该是技术上，但争论的主旨应该是“这将如何让 X 公司赚钱/节省钱，而不是把 Y 公司的钱作为将其添加到我们的工具集的成本”。

问题背景：

我是一家拥有数百名开发人员的公司的开发人员，其中许多人使用 C++。
我有幸（不幸）从我心爱的 Perl 开发地点重新分配到我也在从事 C++ 开发的团队。到目前为止，我发现了许多我可以在 Perl 中轻松完成的事情，而这些事情在 C++ 中非常难以/繁琐（例如 foreach 循环），并且每当我遇到其中之一时，50% 的答案很可能最终是“你在标准 C++ 中无法做到这一点，但您可以使用 Boost 做到这一点”
我们的工具包包括一些遗留的 RogeWave 库，以及数量非常有限的非常古老的 Boost 库（例如，没有 regex，没有 foreach）。
任何开发都必须使用软件工程团队编译和审查的库。这是一个硬性规定。
SE 团队出于各种原因（例如，努力做到这一点；与 RogeWave 的功能冲突，例如 RegEx；安装和使用任何新软件的风险；成本教育开发人员等...）。如果有足够的业务需求或主要令人信服的成本/收益比参数，他们会添加库，但他们有相当严格的门槛。

因此，我正在寻找 Boost 的哪些部分非常出色（具有准确的成本/收益估算）以致于安装它们对于软件工程来说显然是值得付出的努力的示例。

提前感谢您提供任何想法/建议/示例。

请不要将此问题标记为主观，因为我正在寻找可衡量的答案，而不仅仅是美妙的感觉:)

【问题讨论】：

标签： c++ boost

【解决方案1】：

在过去十年中，无论我在哪里工作，当他们有自己的智能指针类时，我都会发现其中的错误 - 通常在几周内。而且，不，我从来没有去看过它，希望能找到错误。

我养成了在TR1 smart pointer proposal 中发布以下引用的习惯：

Boost 开发人员发现共享所有权智能指针极难正确实现。其他人也做出了同样的观察。例如，Scott Meyers [Meyers01] 说：

“STL 本身不包含引用计数智能指针，并且编写一个好的指针 - 一个始终正常工作的指针 - 非常棘手，除非你必须这样做，否则你不想这样做。我发布了代码对于 1996 年更有效的 C++ 中的引用计数智能指针，尽管它基于已建立的智能指针实现并将其提交给经验丰富的开发人员进行广泛的预发布审查，但多年来还是有少量有效的错误报告。引用计数智能指针失败的微妙方式有很多。”

加上对我发现的错误的详细分析，我通常可以将 boost 库合并到代码库中。 :)

【讨论】：

【解决方案2】：

在我看来，您这样做是错误的。由于添加新库的提议会遇到很多阻力，因此作为一个整体，甚至不要试图为提升而争论。而是选择你的战斗。

找到您知道的特定 Boost 库（根据您对要使用的应用程序的了解）将是有用的，并且可以节省时间和金钱。然后建议添加这些。

我可以轻松列出我发现有用的 Boost 库，以及为什么我认为它们很棒，但我不知道它们是否会在您的应用程序中任何使用。

推动包含单独的 boost 库，然后也许，随着时间的推移，它们中的许多将被包含在内，以至于每个人都只包含所有 Boost 会更简单。

【讨论】：

这可能是我需要采取的路径。问题是，虽然特定的 boost 库所需的宣传量少于整个 shebang，但它仍然需要在成本/收益水平上同样令人信服和详细。而且我没有足够的 C++ 经验来自己提出这些论点（这些天我在技能方面是 95% 的 Perl 人）
很公平，但问题是我们其他人并不真正知道哪些 boost 库与您的应用程序相关。大多数人发现智能指针非常有价值，我倾向于大量使用 type_traits，但除此之外，哪些库是相关的确实是特定于领域的。

【解决方案3】：

这是一个不受特定公司控制的开放标准（无许可费用）
它是跨平台的
经过专业设计/编写，非常快速/高效，经过广泛测试
您的团队可以自行编译一些开源实现。
Boost 将很快成为标准 C++ STL 的一部分

这是 Dobbs 博士在 2005 年发表的一篇稍显陈旧的文章，讨论了即将到来的 C++0x 标准。

http://www.ddj.com/cpp/184401958

【讨论】：

+1 - 除了不是所有的 Boost 都被纳入下一个 C++ 标准，但 Boost 无疑对新标准产生了重大影响。
最后一点不是反对提升吗？如果几年后将作为标准的一部分提供，他们为什么要完成添加新库的所有文书工作？
@jalf，如果他们必须通过所有的文书工作来添加一个库，想象一下他们需要做多少工作才能被允许将他们的语言升级到 C++0X（无论何时出来）
@glen - 阿门。整个问题不在于他们反对 Boost，而是他们需要对任何工作、变更和中断进行成本/收益分析。
@Robert - 虽然这些都是好的和正确的观点，但它们都没有提供软件工程团队所需的实际成本/收益分析。我需要特定的“与 Boost 相比，这个特性需要 3 倍的时间来维护本土代码”，“如果没有 Jon Skeet，这个特性是不可能编写的，但是在 Boost 中，每 10000 行代码可以为你节省 3 小时的开发工作" 参数类型。

【解决方案4】：

我不得不在 Solaris 系统上使用来自 Roguewave 的老式 Tools.h++ 来维护一个组件。

在 Solaris 上，如果我们想使用 boost，我们需要使用 gcc 或带有标准 STLport 实现的 SunStudio（而不是 Roguewave 之一）。由于 Tools.h++ 需要旧的 Roguewave 标准前标准实现——在 Solaris 上——我不得不放弃 boost。

最后，我重写了一些我需要的类似于 boost 的功能的简化版本。

如果您处于同样的情况 (*) ，您将无法从 Roguewave 库迁移以轻松提升它。此操作的成本不可忽略，例如两个库中的指针容器具有完全不同的接口。

(*) 我们不能缓慢地逐位更改旧代码以逐步使用 boost。在这种情况下，迁移必须是激进的，并同时将所有出现的 Tools.h++ 更改为更时尚甚至更好的东西。

注意：大多数人都能够在旧项目中逐步使用 boost，但可能会错过一个非常重要的，而且是技术性的点。因此我的否定答案。

【讨论】：

【解决方案5】：

Boost 是一个很棒的工具，也是我们产品开发的宝贵组成部分（如果没有 smart_ptr，我们会迷失方向）...但是因为它变化如此之快，版本的稳定性可能会受到影响。

例如，我们很高兴推出新版本的 Boost，因为它们一出来就没有三思而后行。直到我们在 1.35 线程库中遇到了一个错误，该错误会产生偶尔（即难以调试）但严重的错误。幸运的是，我们在向公众发布任何内容之前就发现了这个问题，并且可以回到 1.34。

从那时起，我们就采用了特定版本，对其进行了广泛的测试，并且在没有令人信服的理由的情况下不会进行更新。

【讨论】：

是的。这就是我所反对的——（对我们公司来说非常正确）如果它没有破坏开发理念，就不要修复它。这对于开发稳定的代码非常有用，但需要加倍努力来引入新的和令人兴奋的东西，当新事物值得时。

【解决方案6】：

以下是提倡boost的两条建议：

谁在使用 Boost？ (http://www.boost.org/users/uses.html)

许多主要项目都使用 boost：（例如，adobe photoshop、CERN）

提高项目成本 (http://www.boost.org/development/index.html)

聘请团队从头开始编写 boost 需要多少费用？那里有一个漂亮的（有点花哨的）计算器，可以帮助您正确看待它。

【讨论】：