为什么C ++游戏开发人员不使用Boost库？[关闭]

因此，如果您花任何时间在C ++标签下的Stack Overflow上查看/回答问题，您将很快注意到几乎每个人都在使用boost库。甚至有人说如果不使用它，就不是在编写“真正的” C ++（我不同意，但这不是重点）。

但是接下来是游戏行业，它因使用C ++ 而未使用boost 而闻名。我不禁想知道为什么会这样。我不在乎使用boost，因为我现在将游戏作为一种爱好来编写，而这种爱好的一部分是在能够实现我需要的东西时实现，而在没有能力的时候使用现成的库。但是，这只是我。

为什么游戏开发人员通常不使用Boost库？是性能还是内存问题？样式？还有吗？

我本想在堆栈溢出时问这个问题，但我认为这里最好问这个问题。

编辑：

我意识到我不能代表所有游戏程序员，而且我还没有看过所有游戏项目，所以我不能说游戏开发人员从不使用Boost。这仅仅是我的经验。

请允许我编辑我的问题，并问，如果您确实使用boost，为什么选择使用它？

有些开发人员这样做，有些开发人员却没有（在游戏和其他地方）。这取决于这些开发人员的需求/要求，以及他们必须利用哪些现有技术。

C ++的标准库经常被给予相同的待遇，人们常常也想知道您对它想知道的同样的事情。大多数原因类似，例如：

• 开发人员可能已经拥有内部功能库，该库提供与标准库或Boost提供的服务相同的服务。这种内部库通常是在很久以前编写的，当时对标准库的实现支持很弱，而Boost基本不存在，因此或多或少必须编写它们。在这种情况下，通常不值得从内部功能转移过来，这将是一项重大的移植工作，它将破坏许多代码的稳定性，并且几乎没有任何好处。

• 开发人员可能正在一个平台上工作，在这些平台上，对Boost所支持的高级C ++技术的编译器支持得不到很好的支持，因此Boost代码根本无法编译或性能很差。这也适用于标准库，尽管如今情况已不是如此。

• Boost和语言的标准库是通用的，虽然对大多数应用程序来说都是不错的选择，但是有时开发人员有特定的需求，而这些需求可以通过更专业的容器来更好地解决。

我认为以上是两个合理的原因，尽管当然还有其他原因。但是，您必须要小心，因为有许多避免使用Boost，标准库或任何归结为“在这里未发明”综合症的原因，这可能表明该原因并非基于实际情况。

还请记住，大型工作室的需求通常与单个开发人员的需求有很大不同。例如，单个开发人员可能需要较少的旧代码来进行维护，因此从本地版本的Boost或标准库功能进行移植可能不会浪费很多时间，并且可以节省开发人员的维护时间将来会广泛使用该代码-因此使我的第一个要点无效。

最后，这是关于根据您的目标评估您的需求和时间投入，并确定哪种选项最能满足您的需求。不使用Boost或标准库的开发人员通常会这样做并得出结论-也许您也会这样做，也许不会。

编辑几年后回到此问题在
继续使用越来越多的boost库之后，我想我会更新此问题，以提供一个可靠的案例，说明为什么当产品说明与所需功能匹配时，您应该使用boost。这将说服反对者。下载openSSL，尝试使用它制作一个客户端和服务器应用程序。现在，尝试使它在每个平台上都能工作。然后，下载并使用boost :: asio :: ssl制作相同的应用程序。如果您不相信boost是寻找干净，优化，经过同行评审的跨平台代码的正确地方，那么此简单的练习将为您带来转换。

tl; dr版本：

在我看来，您不会看到大量独立的或中小型的开发公司在使用Boost，因为它是一种庞大而强大的野兽，很难驯服，并且在尝试学习如何进行时基本上是自己的使用它。在某些方面缺少文档（请参阅长版），并且项目周围的“社区”似乎丢失，分散或不活跃（与其他项目相比）。

非常漫长的版本：

我知道已经有一个可以接受的答案，但是作为实际上在我所做的每个项目中都使用boost的人，我想我会发布一个答案。

我记得当我初次接触增强功能时，老实说我不知道​​发生了什么。Boost并没有得到很好的记录。我敢肯定，人们可能不同意我的观点，因为其中有大量的示例代码片段和注释等，但这都是非常冷淡，含糊且难以导航的。

此外，似乎很难找到在项目周围找到“社区”的任何地方。实际上，社区似乎不存在，或者是游牧民族。不幸的是，即使是他们的邮件列表，也被很多水ech站点所拖曳，您可以沿着这个兔子洞走下去，总是回滚到起点。

这两个因素使学习使用Boost库成为一项相当艰巨的任务。即使使用boost的技术不是太复杂，它也是一个庞大的库集，当您所需要的只是一些代码片段和从Internet上最黑暗的角落分散下来的邮件列表时，就会凝视它... 反正你懂这个意思。

我开始尝试在1.45版附近进行增强，直到现在在1.52 / 1.53版中，我才足够舒服地在生产中使用它。有很多事情要习惯和记住，甚至是简单的事情，例如您如何配置boost和记住该配置，因为库的构建方式和功能可能会根据您在编译时的喜好而发生巨大变化，这取决于可定制的事物是。

但是，请不要误解，一旦您可以使用boost，您就拥有了快速构建可靠的，跨平台程序的强大武器。仅举一个boost::asio例子。您仅需几百行就可以编写一个功能强大，可扩展且坚如磐石的跨平台异步Web服务器。多年来，我编写了多个客户端，服务器，代理等，每行只有几百行代码，但还没有让我失望，并且可以在几分钟内将它们从一个平台移植到另一个平台。

正如其他人指出的那样，大型公司通常会留有遗留的东西，或者喜欢自己推出自己完全理解的东西。在开发主管和/或项目经理禁止使用Boost的过程中，我也曾听说过并遇到这种非常愚蠢的事情，因为Boost太大了。我的猜测是，他们认为boost是1个单一库，或者他们从未听说过BCP。

至于为什么我选择使用升压

我说我使用它是因为您在您的问题中暗示它是“ the” C ++库。Boost在C ++世界中被视为瑞士军刀，最终您将需要使用它们。因此，想法是，如果有需要，应该有一个高性能的便携式版本。大公司为促进工作做出了贡献，受过良好教育的人以令人印象深刻的简历做出了贡献，并保持了这种状态，而当开发新的C ++标准时，人们通常会寻求推动，看看其中哪些部分应成为ISO标准化C ++。

因此，如果我需要添加一些可能存在现有库的功能，那么我将首先看到的地方就是boost，因为我敢打赌它的优化性，可移植性非常好，它将得到支持和维护很长的时间，将发现并处理错误。在开源世界中，很难获得这些品质。

我们在以前的工作场所中使用了一些Boost。主要避免使用它并限制其使用的主要原因是：

• 编译时间-有些编译速度很慢，您最终不愿意在任何标头中使用boost #includes
• 复杂性-大多数游戏开发人员并不了解它，因此导致了不可读的代码
• 性能-默认情况下，某些概念执行缓慢。shared_ptr

对于“更标准”的STL，有人说过同样的话。本文讨论了EASTL，这是Electronic Arts对STL（部分）的内部重写，以适应游戏开发的需求，而这些需求与“更通用”的应用程序开发的需求截然不同。

因此，也许某人正在重写（部分）提升以适应他们在游戏开发中的需求！

谁说他们不使用boost？我知道一两个使用Boost的C ++引擎。我从来没有直接与他们合作过；但这主要是因为我的经验在于虚幻。

由于我没有使用boost的原因，这些都是主观的：

• 我们喜欢滚动特定于我们要部署到的平台的数据结构
• 我们喜欢限制必须在项目中使用的非内部开发代码的数量，尤其是当该外部代码依赖于其他外部开发的库时。

基本上可以归结为：通用解决方案并不总是“合适的”。

我敢肯定，实际上在图书馆工作的人可以发表更好的评论。

我在StackOverflow上闲逛，不使用boost。我将补充我的理由，因为这是一个尚未提及的理由。

实际上，Boost有很多很棒的主意。我喜欢看他们所做的事情，并尝试新事物和新想法。它们很棒，因为它是许多C ++改进的温床。

但是由于许多原因，这种提振是非常笨拙的野兽。原因之一是它们实际上需要（想要）与任何具有怪癖的编译器兼容。结果，他们需要采用许多技巧，例如MPL才能实现。例如（很久以前），我想使用它们的shared_ptr，使其运行就意味着我需要感觉像是90％的提升的源和库。我最终写了我自己的；50条可读的代码行。（我的要求更严格，例如没有weak_ptr或线程安全。）

通常，您只需要一小部分助推器，但是将整个助推器整合在一起根本不值得麻烦。

编辑：

只是要弄清楚，因为它似乎还没弄清楚（即下注）。我使用确实使用第三方库。但是在大多数情况下，在所有条件都相同的情况下，集成或增强第三方库，另一个第三方库更快，更干净。其余的通过“ 2h”手指运动完成。在构建或购买问题上，我的确很认真。

在我们的情况（不是游戏）中，我们有一个不使用boost（也没有std）的充分理由：我们有很多可以追溯到十年的代码。根据前辈的说法，std和boost要么不完整，到处都是错误，要么对于我们所需的高性能而言太慢了。因此，使用相同的概念（例如迭代器）实现了一些基类，并且通常针对我们的算法进行了优化。如今，所有三个库（我们的库，标准库和增强库）都非常相似。

但是我们要移植所有代码吗？并不是的。我认为许多其他公司都面临着同样的困境。要么重写大量经过测试的工作代码，要么不使用std / boost。

在制作游戏时，我并不亲自使用boost或任何其他通用代码，因为游戏不是通用的。实现游戏可能需要的代码类型通常是特定于游戏开发的，而并非总是98％（随机数字）。您可以添加来自boost或其他一些lib的最后几段代码，但可能最好只是在这里和那里写出您需要的那部分。

附带一提，我认为用c ++编写自己的代码很有趣，这就是为什么我从不使用boost或类似的东西。

内部库中的遗留因素不是一个因素...任何人都不应该使用boost其他通用库的主要原因是因为它们没有优化速度和内存，所以我不得不提到Cryengine使用STL但可以编译它使用了一个称为STLPort的开源版本，因此不必担心使用STL，只需实现您的自定义分配器就可以了。不要使用boost。