升压宣传 - 帮助需要(Boost advocacy - help needed)

可能的重复
有没有理由不使用升压？
什么是用C ++ Boost库的优势是什么？

OK，高层次的问题是“请给我提供你认为什么是为什么整个加速的最有效的论据，或者它的某些特定部位，应该我们公司的系统上编译和软件工程标准的认可”。

什么，我需要的详细信息：

• 非常乐意接受正面论据（为什么安装），以及对可能反驳我都听见提出反驳（见下面的问题上下文）。

• 参数应针对这两个技术软件工程团队成员和/或技术性很强的高级管理人员-换言之，对于后者，参数的细节可能/应该是技术，但争论的要点应该是“会怎样本作/保存的X公司的钱VS失去了Y公司的钱，因为它增加了我们的工具包”的成本。

这个问题的背景下：

• 我在一家公司开发拥有几百个开发者，许多人dosens做C ++。

• 我从我心爱的Perl开发当场被重新分配到一个团队里，我也做C ++开发（MIS）的财富。 到目前为止，我发现很多事情，我可以很容易地在Perl中做到这一点是很难/繁琐的C ++做++（foreach循环为例），并随时我打了其中的一个，答案50％可能最终被“你在标准C不能做到这一点++，但你可以用升压做”

• 我们的工具包包括一些传统RogeWave库和Boost库的数量非常有限（例如，没有正则表达式，没有的foreach），很旧的老式的。

• 任何发展必须使用软件工程团队编制和审核库。 这是一个硬性规定。

• SE团队增加新的图书馆，对各种原因（例如，为了做到这一点一定的抗拒;与RogeWave功能冲突，例如用于正则表达式;安装和使用任何新的软件的风险;教育开发等成本.. ）。 他们将添加库如果带有足够的业务需求或majorly令人信服的成本/效益比的说法，但他们有非常艰难的门槛。

所以，我在找的例子，其中升压的部分是如此美妙（包括确切的成本/收益估计），安装起来会是一个很明显值得IT工作的软件工程。

在此先感谢您的任何想法/建议/例子。

请为我寻找答案衡量，而不仅仅是精彩的感情没有标记这个问题是主观的:)

Answer 1:

无论我在过去十年的工作，当他们有他们自己的智能指针类，我发现在错误 - 通常在几个星期。 而且，不，我从来没有去，看着它希望能找到错误。

我钻进发布从下面的报价习惯TR1智能指针的建议 ：

助推开发者发现了一个共享所有权的智能指针非常困难的正确实施。 其他人也犯了同样的观察。 例如，斯科特迈尔斯[Meyers01]表示：

“STL的本身不包含任何引用计数智能指针，写一个很好的 - 一个正常工作所有的时间 - 足够棘手，你不想要，除非你必须这样做，我出版了代码的参考1996年-counting智能指针更有效的C ++，尽管它基础上建立的智能指针实现并提交了广泛的预发布由经验丰富的开发人员审查，有效的bug报告小游行已经流淌在多年。微妙的数其中引用计数智能指针可以失败的方式是显着的。”

这再加上我发现了这个错误（或多个）进行了详细分析，通常把我纳入升压库到代码库中的工作。 :)

Answer 2:

在我看来，你这个做周围的错误的方式。 由于建议增加新的库将有很大的阻力得到满足，甚至不打扰试图主张提升作为一个整体 。 选择你的战斗吧。

找到您知道（你这是要使用的应用程序的知识）的具体Boost库将是有益的和节省时间和金钱。 然后提出加入的。

我可以很容易地列出了Boost库，我发现有用的，所以我觉得他们是伟大的，但我不知道他们是否会在你的应用程序的任何使用。

被列入推动个人Boost库，然后也许，随着时间的推移，他们中许多人将被列入，这将是为大家简单的只包括所有的Boost。

Answer 3:

1. 它不是由特定的企业控制的开放式标准（无许可费用）
2. 它是跨平台
3. 它的专业设计/写入和非常快速/高效广泛的测试
4. 有开源实现，你的团队可以编译自己。
5. 升压即将成为标准C ++ STL的一部分

这里是多布斯医生稍微老气2005年的文章在讨论即将到来的C ++ 0x标准。

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

Answer 4:

我不得不保持使用旧复古的Tools.h ++从Roguewave，组件在Solaris系统上。

在Solaris上，如果我们要使用升压，我们需要为使用GCC或SunStudio与STLport实现标准（而不是Roguewave之一）的。 而作为的Tools.h ++需要老Roguewave预标准执行标准 - 在Solaris上 - ，我不得不放弃提升。

最后，我改写的，我需要一些刺激样特征的简化版本。

如果你是在相同的情况下（*），你将无法从Roguewave库转移到提高，很容易。 有在此操作不可忽略的成本，因为从两个库实例指针容器具有完全不同的接口。

（*）如果我们不能慢慢的旧代码，逐步使用boost位更改位。 在这种情况下，迁移必须是激进的，并通过一些更新潮，甚至更好的同时改变的Tools.h的每次出现++。

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

Answer 5:

升压是一个伟大的工具，我们的产品开发（我们会失去没有smart_ptr）的一个非常宝贵的一部分......但因为变化太快释放的稳定性进行。

例如，我们高兴地只要他们出来不三思而后行引入加速的新版本。 也就是说，直到我们用在1.35线程库（即难以调试）中的错误所产生偶尔但严重错误刺痛。 幸运的是我们确定的问题之前，任何被公布于众，并可能迁回至1.34。

从那时起，我们已经采取了具体的版本，广泛的测试它，而不是更新没有令人信服的理由这样做。

Answer 6:

下面是崇尚升压两点建议：

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

许多重大项目的使用boost：（例如，Adobe公司的Photoshop，CERN）

加速项目成本 （ http://www.boost.org/development/index.html ）

这多少费用聘请一个团队从头编写提升？ 有一个漂亮的（有点花哨）计算器那里，有助于正确看待它。

文章来源: Boost advocacy - help needed